Building binutils at the same time as GCC

[ocaisa]

It looks like building binutils at the same time as GCC is quite common:
http://stackoverflow.com/questions/1726042/recipe-for-compiling-binutils-gcc-together
This could avoid some of the overhead we currently have in getting to our GCC build. It's at least worth a bit of investigation.

Linuxfromscratch do it in as a bootstrap though and it might be good to understand why:
http://www.linuxfromscratch.org/lfs/view/development/index.html

[boegel]

This makes a lot of sense to me, it would make this situation a lot simpler (no more flex/zlib/M4/Bison/binutils modules built with dummy and GCCcore, so 10 less modules).

I do wonder how this mixes with GCCcore though, since you'd get a GCCcore-4.9.3-2.25.eb, and then GCC-4.9.3-2.25.eb basically becomes a trivial wrapper around that GCCcore?

$ eb easybuild/easyconfigs/g/GCC/GCC-4.9.3-2.25.eb -D
== temporary log file in case of crash /var/folders/8s/_frgh9sj6m744mxt5w5lyztr0000gn/T/eb-HXk8y3/easybuild-oCceJP.log
Dry run: printing build status of easyconfigs and dependencies
CFGS=/Users/kehoste/work/easybuild-easyconfigs/easybuild/easyconfigs
 * [ ] $CFGS/f/flex/flex-2.5.39.eb (module: flex/2.5.39)
 * [ ] $CFGS/z/zlib/zlib-1.2.8.eb (module: zlib/1.2.8)
 * [ ] $CFGS/m/M4/M4-1.4.17.eb (module: M4/1.4.17)
 * [ ] $CFGS/b/Bison/Bison-3.0.4.eb (module: Bison/3.0.4)
 * [ ] $CFGS/b/binutils/binutils-2.25.eb (module: binutils/2.25)
 * [ ] $CFGS/g/GCCcore/GCCcore-4.9.3.eb (module: GCCcore/4.9.3)
 * [ ] $CFGS/f/flex/flex-2.5.39-GCCcore-4.9.3.eb (module: flex/2.5.39-GCCcore-4.9.3)
 * [ ] $CFGS/z/zlib/zlib-1.2.8-GCCcore-4.9.3.eb (module: zlib/1.2.8-GCCcore-4.9.3)
 * [ ] $CFGS/m/M4/M4-1.4.17-GCCcore-4.9.3.eb (module: M4/1.4.17-GCCcore-4.9.3)
 * [ ] $CFGS/b/Bison/Bison-3.0.4-GCCcore-4.9.3.eb (module: Bison/3.0.4-GCCcore-4.9.3)
 * [ ] $CFGS/b/binutils/binutils-2.25-GCCcore-4.9.3.eb (module: binutils/2.25-GCCcore-4.9.3)
 * [ ] $CFGS/g/GCC/GCC-4.9.3-2.25.eb (module: GCC/4.9.3-2.25)
== Temporary log file(s) /var/folders/8s/_frgh9sj6m744mxt5w5lyztr0000gn/T/eb-HXk8y3/easybuild-oCceJP.log* have been removed.
== Temporary directory /var/folders/8s/_frgh9sj6m744mxt5w5lyztr0000gn/T/eb-HXk8y3 has been removed.

[boegel]

Well, it may expose issues with zlib, unless you make very sure the system zlib is linked in statically.

So, maybe it doesn't get rid of one of the zlib modules (the one built with dummy).

[wpoely86]

Seems like a lot of potential trouble to me. If you want to avoid dummy stuff, why not create another bootstrap script that build GCCcore? All the dummy stuff is put in a temporarily location and delete afterwards. Seems more flexible to me then extending and complicating the GCC easyblock.

[boegel]

Well, the procedure is well documented (on stackoverflow :P).

I don't think telling people to use a separate bootstrap script rather than just letting eb handle it is a good idea.

[ocaisa]

In stackoverflow, they mention problems with binutils 2.25 in this approach. There is a binutils 2.25.1 and I wonder if that might solve whatever is the source of that problem. This might be a fun debate/project for the User Meeting?