Thanks Kenneth (and others). My situation is exactly what you mentioned below (CentOS 6 on haswell). I actually had started down the path of building on top of the GNU toolchain, but wasn’t sure that was the best path since I then had to change most other builds to use that (or try…) instead of GCC. Hacking the GCC module to include binutils seemed simpler than changing other stuff to use GNU though I don’t disagree that is probably the right way to do it.
I am also curious if there is a description describing the direction you are heading with the toolchain naming convention. Isn’t the foss just a rename of the goolf toolchain? Thanks, Brett > On Sep 2, 2015, at 8:08 AM, Kenneth Hoste <[email protected]> wrote: > > Hi Brett, > > On 02/09/15 14:56, Bode, Brett wrote: >> How do you handle the binutils dependency for other software (like mpich)? I >> have been using the GCC-4.9.2-binutils-2.25 version on a haswell node. >> Binutils is required to build GCC, but it is also required to build other >> software with GCC. However, those packages do not list binutils (either >> version) as a dependency. My hack to get around the problem was change the >> plain binutils module in a regular “dependency” rather than a >> builddependency. Probably not the best solution but to be honest I think the >> GCC-4.9.x-binutils-2.25 sort of implies that it is included. > > Up until now, we relied on the OS-provided binutils. > > With the GNU toolchain and the 2015b 'common' toolchains that are constructed > on top of GNU, we're now pulling binutils into the mix as well, which proved > necessary on RHEL6/Haswell systems (since the older binutils there didn't > support AVX2 yet, at least for a while). > > If you use GNU as a toolchain rather than GCC, you'll have an EB-provided > binutils in your build environment via the toolchain, and there's no need to > include binutils as a (non-build) dependency. > > The reason we're doing it like this is to use a binutils that was built with > the GCC we build ourselves (as opposed to one that was built with the OS > compiler). > > The name GCC-4.9.x-binutils-2.25 just means that this GCC build was done > using that specific version of binutils (yet one that was built with the OS > compiler, which is not what we want to end up using). > > Does that make sense? > > > regards, > > Kenneth >> >> Brett >> >>> On Sep 2, 2015, at 7:42 AM, Ward Poelmans <[email protected]> wrote: >>> >>> On Wed, Sep 2, 2015 at 2:39 PM, Backeljauw Franky >>> <[email protected]> wrote: >>>> I’m wondering: why do I have both binutils/2.25 and >>>> binutils/2.25-GCC-4.9.3-binutils-2.25 (the same for Bison, flex, M4, zlib)? >>>> Are the non-GCC-versions actually used, or are they just dependencies >>>> needed to built the GCC-versions? >>> binutils/2.25 is build with the system compiler and used to bootstrap >>> GCC. After that we build binutils/2.25-GCC-4.9.3-binutils-2.25 and use >>> it. Bison & co are deps needed to build binutils. >>> >>> In principle, you can delete binutils/2.25 (and deps). >>> >>> Ward >
