1339989 - Create a sixgill compilation toolchain job

Status: RESOLVED FIXED

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Steve Fink [:sfink] [:s:]]

Updating sixgill has traditionally been difficult, since it needs to build in our automation environment.

So build it in our automation environment.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Create a sixgill compilation toolchain job

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.

Comment 2

[Mike Hommey [:glandium]]

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.

Comment 3

[Steve Fink [:sfink] [:s:]]

(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.

Comment 4

[Steve Fink [:sfink] [:s:]]

Attachment: Create a sixgill compilation toolchain job

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.

Comment 5

[Steve Fink [:sfink] [:s:]]

Attachment: Add --download-only option to build-gcc.sh

Comment 6

[Steve Fink [:sfink] [:s:]]

Attachment: Add --download-only option to build-gcc.sh

this is probably more idiomatic

Comment 7

[Steve Fink [:sfink] [:s:]]

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.

Comment 8

[Mike Hommey [:glandium]]

(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)

Comment 9

[Mike Hommey [:glandium]]

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.

Comment 10

[Mike Hommey [:glandium]]

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.

Comment 11

[Steve Fink [:sfink] [:s:]]

Attachment: Add --download-only option to build-gcc.sh

Comment 12

[Mike Hommey [:glandium]]

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?

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/7ac6454c755a
Add --no-build option to build-gcc.sh, r=glandium

Comment 14

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/7ac6454c755a

Comment 15

[Steve Fink [:sfink] [:s:]]

Attachment: Create a sixgill compilation toolchain job

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.

Comment 16

[Mike Hommey [:glandium]]

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.

Comment 17

[Steve Fink [:sfink] [:s:]]

(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.

Comment 18

[Mike Hommey [:glandium]]

(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.

Comment 19

[Steve Fink [:sfink] [:s:]]

Attachment: Create a sixgill compilation toolchain job

The try push of this updated patch looks to have succeeded, and the downstream hazard build seems to be using the result successfully.

Comment 20

[Steve Fink [:sfink] [:s:]]

(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.

Comment 21

[Mike Hommey [:glandium]]

(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.

Comment 22

[Steve Fink [:sfink] [:s:]]

(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 23

[Mike Hommey [:glandium]]

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.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/78eb19c1cbfa
Create a sixgill compilation toolchain job, r=glandium

Comment 25

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/mozilla-central/rev/78eb19c1cbfa

Comment 26

[Steve Fink [:sfink] [:s:]]

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.

Comment 27

[Steve Fink [:sfink] [:s:]]

This had a stray leave-open.