Closed Bug 1339989 Opened 8 years ago Closed 7 years ago

Create a sixgill compilation toolchain job

Categories

(Developer Infrastructure :: Source Code Analysis, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: sfink, Assigned: sfink)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 6 obsolete files)

Updating sixgill has traditionally been difficult, since it needs to build in our automation environment. So build it in our automation environment.
This depends on gmp, which is a prerequisite of gcc. I want to get the same version that we use with gcc, just for simplicity. But the logic for choosing and downloading the right version is buried in build-gcc.sh. This patch takes the least-effort path and just runs build-gcc.sh first, even though we don't need the actual gcc build, just to get the gmp source directory. I'm sure there are better ways of doing this.
Attachment #8837848 - Flags: review?(mh+mozilla)
Comment on attachment 8837848 [details] [diff] [review] Create a sixgill compilation toolchain job Review of attachment 8837848 [details] [diff] [review]: ----------------------------------------------------------------- Sorry it took so long. Bug 1354395 gave me the kick to go through all of this. ::: build/unix/build-sixgill/build-sixgill.sh @@ +2,5 @@ > + > +sixgill_rev=946bc475b7fc > +gcc_version=4.9.4 > +sixgill_repo=https://hg.mozilla.org/users/sfink_mozilla.com/sixgill > +this_path=$(readlink -f $(dirname $0)) You're not using this @@ +3,5 @@ > +sixgill_rev=946bc475b7fc > +gcc_version=4.9.4 > +sixgill_repo=https://hg.mozilla.org/users/sfink_mozilla.com/sixgill > +this_path=$(readlink -f $(dirname $0)) > +make_flags='-j12' nor that @@ +23,5 @@ > +# cc1/cc1plus. So link the plugin statically to libgmp. Except that the default > +# static build does not have -fPIC, and will result in a relocation error, so > +# build our own. This requires the gcc source checkout. > +mkdir $root_dir/gmp-objdir || true > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) You should build explicitly without the shared library (--disable-shared), build with --prefix=/tools/gmp and do make install DESTDIR=$root_dir @@ +24,5 @@ > +# static build does not have -fPIC, and will result in a relocation error, so > +# build our own. This requires the gcc source checkout. > +mkdir $root_dir/gmp-objdir || true > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) > +export EXTRA_LDFLAGS=$root_dir/tools/gmp/lib/libgmp.a I see you removed -lgmp from the sixgill repo. That doesn't seem right. You should add -lgmp back there (and add it where it was missing, e.g. for xdb.so) and add the right -L through here or some other way. You may want to add -Wl,-z,defs in sixgill's Makefile too. @@ +26,5 @@ > +mkdir $root_dir/gmp-objdir || true > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) > +export EXTRA_LDFLAGS=$root_dir/tools/gmp/lib/libgmp.a > + > +hg clone -r $sixgill_rev $sixgill_repo || ( cd sixgill && hg update -r $sixgill_rev ) It feels like this should use tc-vcs. @@ +34,5 @@ > +export TARGET_CC=$CC > +export CPPFLAGS=-I$root_dir/tools/gmp/include > +export HOST_CFLAGS=$CPPFLAGS > + > +perl -i.bak -lpe '$_ .= " -Wno-error=pointer-sign" if /^WARNINGS =/' Makefile Seems like a change that should be done in the sixgill repo itself. ::: js/src/devtools/rootAnalysis/build/sixgill.manifest @@ +1,5 @@ > [ > { > +"digest" : "ef6ea085e1fc0ce5c2441b3b82b02312da8e879226d36da53489021c7205860191e61924f7b536ab10f8838551656fef88a558b0eff05b07d129074011d3d009", > +"algorithm" : "sha512", > +"hg_id" : "7c41742d2ec5+ tip", There is no such sha1 in the mercurial repo. That's also true for the previous value, btw. You also need to adjust browser/config/tooltool-manifests/linux64/hazard.manifest and b2g/dev/config/tooltool-manifests/linux64/hazard.manifest ::: taskcluster/ci/toolchain/linux.yml @@ +75,5 @@ > + description: "sixgill GCC plugin build" > + treeherder: > + kind: build > + platform: toolchains/opt > + symbol: TL(6g) Not particularly convinced it needs to be abbreviated. @@ +88,5 @@ > + max-run-time: 36000 > + when: > + files-changed: > + - 'build/unix/build-gcc/**' > + - 'build/unix/build-sixgill/**' These two now go under run.resources, and the toolchain.py and main taskcluster shell scripts are not necessary to be listed anymore. ::: taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh @@ +10,5 @@ > +UPLOAD_DIR=$WORKSPACE/artifacts > + > +cd $HOME_DIR/src > + > +build/unix/build-gcc/build-gcc.sh $HOME_DIR It would be much much better if we didn't have to waste time building the whole thing.
Attachment #8837848 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] (VAC: Apr 20-May 4) from comment #2) > @@ +23,5 @@ > > +# cc1/cc1plus. So link the plugin statically to libgmp. Except that the default > > +# static build does not have -fPIC, and will result in a relocation error, so > > +# build our own. This requires the gcc source checkout. > > +mkdir $root_dir/gmp-objdir || true > > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) > > You should build explicitly without the shared library (--disable-shared), > build with --prefix=/tools/gmp and do make install DESTDIR=$root_dir Thanks, you're right. I switched to this because -lgmp was preferentially choosing the shared lib (I remember trying -Wl,-static but having problems with it.) But with --disable-shared, you're right and I can go back to using -lgmp. > @@ +24,5 @@ > > +# static build does not have -fPIC, and will result in a relocation error, so > > +# build our own. This requires the gcc source checkout. > > +mkdir $root_dir/gmp-objdir || true > > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) > > +export EXTRA_LDFLAGS=$root_dir/tools/gmp/lib/libgmp.a > > I see you removed -lgmp from the sixgill repo. That doesn't seem right. You > should add -lgmp back there (and add it where it was missing, e.g. for > xdb.so) and add the right -L through here or some other way. You may want to > add -Wl,-z,defs in sixgill's Makefile too. Yes, that's much better. > @@ +26,5 @@ > > +mkdir $root_dir/gmp-objdir || true > > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --with-pic --prefix=$root_dir/tools/gmp && make -j8 && make install ) > > +export EXTRA_LDFLAGS=$root_dir/tools/gmp/lib/libgmp.a > > + > > +hg clone -r $sixgill_rev $sixgill_repo || ( cd sixgill && hg update -r $sixgill_rev ) > > It feels like this should use tc-vcs. Doesn't that require installing some other package? Or maybe that's already installed on the TC build machines. And is tc-vcs the current thing, or should I be using hg robustcheckout now? > @@ +34,5 @@ > > +export TARGET_CC=$CC > > +export CPPFLAGS=-I$root_dir/tools/gmp/include > > +export HOST_CFLAGS=$CPPFLAGS > > + > > +perl -i.bak -lpe '$_ .= " -Wno-error=pointer-sign" if /^WARNINGS =/' Makefile > > Seems like a change that should be done in the sixgill repo itself. Hm. I dimly remember agonizing over this.... oh, I think I did this at a time when I was trying hard to pull from bhackett's published svn repo or something? Sorry, I should've cleaned this up more before requesting review. > ::: js/src/devtools/rootAnalysis/build/sixgill.manifest > @@ +1,5 @@ > > [ > > { > > +"digest" : "ef6ea085e1fc0ce5c2441b3b82b02312da8e879226d36da53489021c7205860191e61924f7b536ab10f8838551656fef88a558b0eff05b07d129074011d3d009", > > +"algorithm" : "sha512", > > +"hg_id" : "7c41742d2ec5+ tip", > > There is no such sha1 in the mercurial repo. That's also true for the > previous value, btw. You also need to adjust > browser/config/tooltool-manifests/linux64/hazard.manifest and > b2g/dev/config/tooltool-manifests/linux64/hazard.manifest Sorry, which sha1s? I thought this must be because I've been treating that repo as my own private nonpublishing repo, and those sha1s are obsolete now. But I just cloned, and I found 7c41742d2ec5 to still be live. (It's on an abandoned fork, but it's not obsolete.) We're talking about https://hg.mozilla.org/users/sfink_mozilla.com/sixgill right? Or are you talking about the tooltool sha256? That must exist, given that these jobs are green on try. I'm confused. > ::: taskcluster/ci/toolchain/linux.yml > @@ +75,5 @@ > > + description: "sixgill GCC plugin build" > > + treeherder: > > + kind: build > > + platform: toolchains/opt > > + symbol: TL(6g) > > Not particularly convinced it needs to be abbreviated. Fair. The abbreviation seemed reasonable to me when I had it as SM(6g), but I agree that TL(sixgill) is better than TL(6g). > @@ +88,5 @@ > > + max-run-time: 36000 > > + when: > > + files-changed: > > + - 'build/unix/build-gcc/**' > > + - 'build/unix/build-sixgill/**' > > These two now go under run.resources, and the toolchain.py and main > taskcluster shell scripts are not necessary to be listed anymore. Whoa... thanks. Why is it different between toolchain jobs and build jobs? > ::: taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh > @@ +10,5 @@ > > +UPLOAD_DIR=$WORKSPACE/artifacts > > + > > +cd $HOME_DIR/src > > + > > +build/unix/build-gcc/build-gcc.sh $HOME_DIR > > It would be much much better if we didn't have to waste time building the > whole thing. I can update build-gcc.sh to accept a flag for only doing the checkouts, or even doing specific checkouts. I was just trying to avoid touching anything else for my weirdo niche stuff, but I'm happy to do the work if you'd take it.
Note that this is still using 'hg clone' instead of tc-vcs. I wanted to be sure of what to do there, and I'll have to get a (1click) loaner to figure out what works in the build environment.
Attachment #8858933 - Flags: review?(mh+mozilla)
Attachment #8837848 - Attachment is obsolete: true
Attachment #8858935 - Flags: review?(mh+mozilla)
this is probably more idiomatic
Attachment #8858936 - Flags: review?(mh+mozilla)
Attachment #8858935 - Attachment is obsolete: true
Attachment #8858935 - Flags: review?(mh+mozilla)
Ugh. Using --download-only means that I no longer have access to the gcc binary. I don't know what system gcc is included in the toolchain image, but it seems like I really ought to be compiling the plugin with our exact gcc. (Or at least, using its headers.) If I don't compile it myself, I guess I could pull it down from tooltool. Which I can do, but it seems a little weird, since now I have one toolchain job depending on the manually-uploaded output of another toolchain job. So I guess before I go to the effort of figuring out the cleanest way of wiring up a tooltool download for this job, I'll ask your opinion of what the best way forward is -- tooltool download, compile it locally like I was doing, or depending on the gcc embedded in the image.
Flags: needinfo?(mh+mozilla)
(In reply to Steve Fink [:sfink] [:s:] from comment #7) > Ugh. Using --download-only means that I no longer have access to the gcc > binary. I don't know what system gcc is included in the toolchain image, but > it seems like I really ought to be compiling the plugin with our exact gcc. > (Or at least, using its headers.) > > If I don't compile it myself, I guess I could pull it down from tooltool. > Which I can do, but it seems a little weird, since now I have one toolchain > job depending on the manually-uploaded output of another toolchain job. We're already doing that all over the place. Fortunately, bug 1313111 is close to completion. > So I guess before I go to the effort of figuring out the cleanest way of wiring > up a tooltool download for this job, I'll ask your opinion of what the best > way forward is -- tooltool download, compile it locally like I was doing, or > depending on the gcc embedded in the image. The purely idealistic solution would be for gcc to be built with libgmp as a shared library, and for the plugin to use that. If using the gcc from the image works, that would be fine too, but I'm not sure it has the necessary support for gcc plugins, and if it has, if it's compatible. I think the system gcc is old enough that it's likely a problem. And until bug 1313111, a tooltool download would be preferable. Depends if you can wait or not. If not, it would be preferable to use taskcluster/scripts/misc/tooltool-download.sh. Check out how other scripts use it (and, more importantly, how their taskcluster yaml looks like)
Flags: needinfo?(mh+mozilla)
Comment on attachment 8858933 [details] [diff] [review] Create a sixgill compilation toolchain job Review of attachment 8858933 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/unix/build-sixgill/build-sixgill.sh @@ +24,5 @@ > +mkdir $root_dir/gmp-objdir || true > +( cd $root_dir/gmp-objdir && $root_dir/gcc-$gcc_version/gmp/configure --disable-shared --with-pic --prefix=/tools/gmp && make -j8 && make install DESTDIR=$root_dir) > +export EXTRA_LDFLAGS=-L$root_dir/tools/gmp/lib > + > +hg clone -r $sixgill_rev $sixgill_repo || ( cd sixgill && hg update -r $sixgill_rev ) Yeah, looks like my knowledge is outdated, and tc-vcs is deprecated. robustcheckout would seem to be preferable, though. ::: js/src/devtools/rootAnalysis/build/sixgill.manifest @@ +1,5 @@ > [ > { > +"digest" : "ef6ea085e1fc0ce5c2441b3b82b02312da8e879226d36da53489021c7205860191e61924f7b536ab10f8838551656fef88a558b0eff05b07d129074011d3d009", > +"algorithm" : "sha512", > +"hg_id" : "7c41742d2ec5+ tip", Presumably, you're updating to the result of the (new) sigxgill job. So this should be the same as sixgill_rev in the script, right? ::: taskcluster/ci/toolchain/linux.yml @@ +67,5 @@ > + treeherder: > + kind: build > + platform: toolchains/opt > + symbol: TL(sixgill) > + tier: 2 The hazard jobs are tier 1. This should be tier 1 too (or at least should be once dependencies are established). @@ +75,5 @@ > + resources: > + - 'build/unix/build-gcc/**' > + - 'build/unix/build-sixgill/**' > + - 'taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh' > + - 'taskcluster/taskgraph/transforms/job/toolchain.py' As mentioned previously, you don't need the last two. toolchain.py adds them on its own. @@ +80,5 @@ > + worker-type: aws-provisioner-v1/gecko-{level}-b-linux > + worker: > + implementation: docker-worker > + docker-image: {in-tree: desktop-build} > + max-run-time: 36000 maybe put the run section last, like in other definitions? ::: taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh @@ +10,5 @@ > +UPLOAD_DIR=$WORKSPACE/artifacts > + > +cd $HOME_DIR/src > + > +build/unix/build-gcc/build-gcc.sh $HOME_DIR Seems like you should do the --download-only thing first.
Attachment #8858933 - Flags: review?(mh+mozilla)
Comment on attachment 8858936 [details] [diff] [review] Add --download-only option to build-gcc.sh Review of attachment 8858936 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/unix/build-gcc/build-gcc.sh @@ +9,5 @@ > this_path=$(readlink -f $(dirname $0)) > make_flags='-j12' > > +download_only= > +if [[ "$1" = "--download-only" ]]; then you don't need the double brackets here. Single brackets would work just fine.
Attachment #8858936 - Flags: review?(mh+mozilla)
Attachment #8859729 - Flags: review?(mh+mozilla)
Attachment #8858936 - Attachment is obsolete: true
Comment on attachment 8859729 [details] [diff] [review] Add --download-only option to build-gcc.sh Review of attachment 8859729 [details] [diff] [review]: ----------------------------------------------------------------- Come to think of it, --download-only is kind of misleading of a name. Maybe --no-build?
Attachment #8859729 - Flags: review?(mh+mozilla) → review+
Keywords: leave-open
Pushed by sfink@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/7ac6454c755a Add --no-build option to build-gcc.sh, r=glandium
Blocks: 1398213
Depends on: 1406570
Adapt the sixgill copmilation job to the new world order. It's working very nicely now, quite a nice cleanup with the new toolchain dependency stuff. There are some workarounds buried in here, still.
Attachment #8916836 - Flags: review?(mh+mozilla)
Attachment #8858933 - Attachment is obsolete: true
Comment on attachment 8916836 [details] [diff] [review] Create a sixgill compilation toolchain job Review of attachment 8916836 [details] [diff] [review]: ----------------------------------------------------------------- ::: taskcluster/ci/toolchain/linux.yml @@ +119,5 @@ > + tier: 1 > + worker-type: aws-provisioner-v1/gecko-{level}-b-linux > + worker: > + docker-image: {in-tree: desktop-build} > + max-run-time: 36000 Please don't cargo cult crazy long timeouts. @@ +124,5 @@ > + run: > + using: toolchain-script > + script: build-gcc-sixgill-plugin-linux.sh > + resources: > + - 'build/unix/build-gcc/**' Please avoid wildcards. ::: taskcluster/scripts/builder/build-haz-linux.sh @@ -52,5 @@ > export MOZ_OBJDIR="$WORKSPACE/obj-analyzed" > mkdir -p "$MOZ_OBJDIR" > > if [ -n "$DO_TOOLTOOL" ]; then > - ( cd $TOOLTOOL_DIR; $GECKO_DIR/mach artifact toolchain -v --tooltool-url https://tooltool.mozilla-releng.net/ --tooltool-manifest $GECKO_DIR/$TOOLTOOL_MANIFEST --cache-dir $TOOLTOOL_CACHE${MOZ_TOOLCHAINS:+ ${MOZ_TOOLCHAINS}} ) See how this lines contains MOZ_TOOLCHAINS? You shouldn't need to touch this file to handle toolchains. ::: taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh @@ +25,5 @@ > +sixgill_rev=59b74c2e21bd > +sixgill_repo=https://hg.mozilla.org/users/sfink_mozilla.com/sixgill > + > +. $data_dir/build-gcc.sh > +. $data_dir/gcc-$gcc_version.sh I'd rather duplicate the contents of build-gcc-4.9-linux.sh than do this. Eventually, we should be able to build sixgill without the gcc source, right? @@ +26,5 @@ > +sixgill_repo=https://hg.mozilla.org/users/sfink_mozilla.com/sixgill > + > +. $data_dir/build-gcc.sh > +. $data_dir/gcc-$gcc_version.sh > +. $build_dir/unix/build-sixgill/build-sixgill.sh You might as well inline that file here. @@ +29,5 @@ > +. $data_dir/gcc-$gcc_version.sh > +. $build_dir/unix/build-sixgill/build-sixgill.sh > + > +prepare > +apply_patch $data_dir/PR64905.patch I don't think you actually need to apply the patch.
Attachment #8916836 - Flags: review?(mh+mozilla)
(In reply to Mike Hommey [:glandium] from comment #16) > Comment on attachment 8916836 [details] [diff] [review] > Create a sixgill compilation toolchain job > > Review of attachment 8916836 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: taskcluster/ci/toolchain/linux.yml > @@ +119,5 @@ > > + tier: 1 > > + worker-type: aws-provisioner-v1/gecko-{level}-b-linux > > + worker: > > + docker-image: {in-tree: desktop-build} > > + max-run-time: 36000 > > Please don't cargo cult crazy long timeouts. I just saw a 36 followed by some zeroes that I didn't bother counting. Hm, I guess that's probably copied from the linux64-gcc-4.9 job. I'll remove the nondefault timeout; this task is fast. > ::: taskcluster/scripts/builder/build-haz-linux.sh > @@ -52,5 @@ > > export MOZ_OBJDIR="$WORKSPACE/obj-analyzed" > > mkdir -p "$MOZ_OBJDIR" > > > > if [ -n "$DO_TOOLTOOL" ]; then > > - ( cd $TOOLTOOL_DIR; $GECKO_DIR/mach artifact toolchain -v --tooltool-url https://tooltool.mozilla-releng.net/ --tooltool-manifest $GECKO_DIR/$TOOLTOOL_MANIFEST --cache-dir $TOOLTOOL_CACHE${MOZ_TOOLCHAINS:+ ${MOZ_TOOLCHAINS}} ) > > See how this lines contains MOZ_TOOLCHAINS? You shouldn't need to touch this > file to handle toolchains. I know, I just thought that given how long and complex this line is, it would be better to remove duplication by reusing tooltool-download.sh. But maybe that script is intended for a different purpose and so might evolve incompatibly? Anyway, I'll revert this change. > ::: taskcluster/scripts/misc/build-gcc-sixgill-plugin-linux.sh > @@ +25,5 @@ > > +sixgill_rev=59b74c2e21bd > > +sixgill_repo=https://hg.mozilla.org/users/sfink_mozilla.com/sixgill > > + > > +. $data_dir/build-gcc.sh > > +. $data_dir/gcc-$gcc_version.sh > > I'd rather duplicate the contents of build-gcc-4.9-linux.sh than do this. > Eventually, we should be able to build sixgill without the gcc source, right? Right. The only thing I'm using the gcc build script for is the gmp source, not even the gcc source. For this task, build-gcc.sh is purely a way of figuring out the correct version of gmp and downloading it, and given that I'm statically linking it, the version probably doesn't even matter very much. > @@ +29,5 @@ > > +. $data_dir/gcc-$gcc_version.sh > > +. $build_dir/unix/build-sixgill/build-sixgill.sh > > + > > +prepare > > +apply_patch $data_dir/PR64905.patch > > I don't think you actually need to apply the patch. I don't, I was mimicking the gcc toolchain task as closely as possible to avoid needing to answer the question of why it differs. But ok, I'll drop it.
(In reply to Steve Fink [:sfink] [:s:] from comment #17) > Right. The only thing I'm using the gcc build script for is the gmp source, > not even the gcc source. For this task, build-gcc.sh is purely a way of > figuring out the correct version of gmp and downloading it, and given that > I'm statically linking it, the version probably doesn't even matter very > much. Note, we should be able to build gmp as a shared library in the gcc "package" itself, and include its headers there, somehow. But I won't block this bug on that.
The try push of this updated patch looks to have succeeded, and the downstream hazard build seems to be using the result successfully.
Attachment #8918034 - Flags: review?(mh+mozilla)
Attachment #8916836 - Attachment is obsolete: true
(In reply to Mike Hommey [:glandium] from comment #18) > (In reply to Steve Fink [:sfink] [:s:] from comment #17) > > Right. The only thing I'm using the gcc build script for is the gmp source, > > not even the gcc source. For this task, build-gcc.sh is purely a way of > > figuring out the correct version of gmp and downloading it, and given that > > I'm statically linking it, the version probably doesn't even matter very > > much. > > Note, we should be able to build gmp as a shared library in the gcc > "package" itself, and include its headers there, somehow. But I won't block > this bug on that. I don't think I can use it as a shared library? I could try again, but it was colliding with the libgmp in cc1plus.
(In reply to Steve Fink [:sfink] [:s:] from comment #20) > (In reply to Mike Hommey [:glandium] from comment #18) > > (In reply to Steve Fink [:sfink] [:s:] from comment #17) > > > Right. The only thing I'm using the gcc build script for is the gmp source, > > > not even the gcc source. For this task, build-gcc.sh is purely a way of > > > figuring out the correct version of gmp and downloading it, and given that > > > I'm statically linking it, the version probably doesn't even matter very > > > much. > > > > Note, we should be able to build gmp as a shared library in the gcc > > "package" itself, and include its headers there, somehow. But I won't block > > this bug on that. > > I don't think I can use it as a shared library? I could try again, but it > was colliding with the libgmp in cc1plus. The point is that cc1plus would use the shared library too.
(In reply to Mike Hommey [:glandium] from comment #21) > The point is that cc1plus would use the shared library too. Ah! Somehow, I didn't even consider that configuration. Ok, that makes a lot of sense.
Comment on attachment 8918034 [details] [diff] [review] Create a sixgill compilation toolchain job Review of attachment 8918034 [details] [diff] [review]: ----------------------------------------------------------------- ::: taskcluster/scripts/builder/build-haz-linux.sh @@ +35,5 @@ > > # Use GECKO_BASE_REPOSITORY as a signal for whether we are running in automation. > export AUTOMATION=${GECKO_BASE_REPOSITORY:+1} > > +: ${GECKO_DIR:=$WORKSPACE/build/src} You shouldn't need to do any change to this file.
Attachment #8918034 - Flags: review?(mh+mozilla) → review+
Pushed by sfink@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/78eb19c1cbfa Create a sixgill compilation toolchain job, r=glandium
Comment on attachment 8859729 [details] [diff] [review] Add --download-only option to build-gcc.sh build-gcc.sh has been rewritten since this was posted, and is now a set of reusable functions that can be called.
Attachment #8859729 - Attachment is obsolete: true
This had a stray leave-open.
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Keywords: leave-open
Resolution: --- → FIXED
Product: Core → Firefox Build System
Product: Firefox Build System → Developer Infrastructure
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: