Open ocaisa opened 8 years ago
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.
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
).
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.
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.
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?
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