Hi Markus,
On 25/10/15 20:14, Markus Geimer wrote:
Hi Ward,
On 10/25/2015 01:32 PM, Ward Poelmans wrote:
On 25-10-15 12:30, Markus Geimer wrote:
I would have expected that binutils are a dependency (rather than a
builddep) of GCC. The reason is that with a hierarchical module
naming scheme, it is perfectly valid to not expose the EB toolchains
to users by not adding 'Core/toolchain' to the default modulepath.
This means that when I (as a software developer) load GCC, I may end
up with a broken installation that can't compile code optimized for
my platform -- depending on the underlying system-provided binutils.
This looks like a major flaw to me...
Hi Markus,
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.
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.
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.
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)?
Or, that loading another (likely newer) GCC isn't going to break that
binutils build?
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.
I do understand that using 'GNU' rather than 'GCC' makes it less
transparent.
I also agree that hiding toolchains for users can make sense.
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.
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...
regards,
Kenneth
