Kenneth, >>> What happens when building the GNU toolchain is: >>> - Build binutils with system GCC >>> - Build GCC using the previous binutils and system GCC >>> - Build binutils with EB GCC >>> - Create GNU toolchain that loads both EB GCC and the previous binutils >> That's understood -- and I believe that this is way too complicated. > > We're just making sure here we don't rely on the system GCC (or its > libraries) in any way.
You know my opinion on this: Sometimes, you are carrying things too far. > Using the system-provided binutils has proven to be an issue sometimes, > for example in RHEL6 on Haswell, where the standard system binutils is > too old to be aware of AVX2. That's why we've opted to provide our own. That's a perfectly valid approach. (Though one could also blame RHEL for shipping ancient software. Even Debian ships a recent enough binutils... ;-)) > How sure are you that a binutils built with the system compiler doesn't > rely on that system compiler anymore at runtime (i.e. what if the system > compiler gets updated, or worse, disappears)? In this particular case, I'm quite sure. None of the binutils binaries or libraries depends on any compiler-provided library. > Or, that loading another (likely newer) GCC isn't going to break that > binutils build? See above. If you are so concerned, let me ask a counter question: How sure are you that simply replacing the underlying binutils in the GNU toolchain doesn't break the GCC compiled using the binutils compiled with the system GCC? To be really on the "safe side", you would have to bootstrap GCC again with the new GCC using the binutils compiled with that GCC. > So, basically, this boils down to changing the name of 'GNU' to 'GCC', > while making sure that binutils is a (runtime) dep of 'GCC'. > > That's not too terrible to fix, except for the tedious naming to > discriminate between a GCC build with a binutils built with the system > compiler vs a GCC build with a binutils built with that same GCC > (version). In the latter, there's a chicken-or-egg situation we need to > dance around. > > Basically, you'd have a 'GCC' compiler (built with a binutils built with > system GCC) and a 'GCC' toolchain (which includes a binutils built with > the GCC compiler we've built). Since both can not be loaded at the same > time, you'd need to rename the GCC compiler module to something else. And you'd have to make sure that only the "right" GCC (in this case, the toolchain) extends the modulepath in a hierarchical scheme. > The support for the 'modaltsoftname' easyconfig parameter that was > recently merged into develop, which you can use to specify an > alternative software name to be used to generate the module name, can > come in useful here. You can define "modaltsoftname = 'GCCcomp'" in the > GCC compiler easyconfigs, in order to get a 'GCCcomp/4.9.3' module for > example. > Currently, this may be problematic when specifying the dependencies > though... This sounds like an evil hack that may turn out to backfire at some point... Markus -- Dr. Markus Geimer Juelich Supercomputing Centre Institute for Advanced Simulation Forschungszentrum Juelich GmbH 52425 Juelich, Germany Phone: +49-2461-61-1773 Fax: +49-2461-61-6656 E-mail: [email protected] WWW: http://www.fz-juelich.de/jsc/ ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------
