Hi Markus, On 25-10-15 20:14, Markus Geimer wrote:
> On 10/25/2015 01:32 PM, Ward Poelmans wrote: >> On 25-10-15 12:30, Markus Geimer wrote: >> >> 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. > >> This is the reason why binutils is a build dep for GCC, we only mean to >> use that binutils once as it was built using the system GCC. > > So what? EB was using a system-provided binutils, which you can assume > to be built with the system GCC, for many years. And I still don't see > what's wrong with a self-compiled binutils using the same compiler. We did it for years until we hit the wall with RHEL 6.x on Haswell hardware. One of the core points of EB is reproducibility and so we cannot really let such an important component in the building process out of our control. That's is also the reason for the why we rebuild binutils with our own GCC. It is the only way to get as close as possible to perfect reproducibility. >> The flaw is that you try to load the GCC module itself while you should >> be loading the GNU module. But the naming is indeed confusing. > > Try to explain this to users. They know GCC as a compiler, and will > load this module if they need a compiler. They (potentially) know GNU > as a collection of UNIX-like tools, and will happily ignore the module. > Also, not every setup requires full toolchains which load "the right > thing" underneath. For example, on our Scalasca mini test cluster, > we don't need any math libraries -- just compilers and MPIs. Thus, > the toolchain concept doesn't gain you very much and it is IMHO > reasonable to hide them. When I load the GCC module, I expect to get > a working compiler -- and if it needs something else as a dependency > to do its job, it should automatically load it. If it doesn't do that, > the flaw is in the GCC module. On this point I agree. The naming is very confusing. We should pick better names and hide modules that should not be loaded by the end user directly. Your assumption that GCC loads a fully working compiler is reasonable, we know have to find a way to let EB do it in the way we want it. And we definitely need subtoolchains. Ward -- dr. ir. Ward Poelmans High Performance Computing infrastructure unit Ghent University Krijgslaan 281 S9 B-9000 Gent Belgium Tel: +32 9 264 4817 http://www.ugent.be/hpc
