GCCcore-6.3.0 should be renamed GCCcore-6.3.0-2.27 before releasing more 2017A packages

[JackPerdue]

The present naming scheme for GCCcore makes it difficult to use alternative implementations of binutils. While trying to track down problems on our latest cluster I've build with binutils 2.24-2.27 as well as against the system binutils (which we are currently calling GCCcore-6.3.0 since the binutils will depend upon the system it is installed on).

I have a shed load of EasyConfigs for our 2017A toolchains built on our variation of GCCcore.., most of which use --minimal-toolchains Given that EB has only provided HPL for 2017a so far, this might be a good time to work on the nomenclature for GCCcore. If I'm too late, I'd like to register a suggestion for the next GCCcore (include the binutils version).

[JackPerdue]

er... subject... I meant 2017a (EB) packages (2017A is our local version)

[JackPerdue]

(shed load being about 250 at the moment... for GRASS/QGIS/R/OpenFOAM*)

[JackPerdue]

Beyond that.. the description is a lie as built.. description = """ The GNU Compiler Collection includes front ends for C, C++, Objective-C, Fortran, Java, and Ada, as well as libraries for these languages (libstdc++, libgcj,...). """

pretty sure the current buld doesn't include ObjectiveC, Java or Ada.

[boegel]

@JackPerdue The GCCcore-6.3.0.eb easyconfig (https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/g/GCCcore/GCCcore-6.3.0.eb) doesn't include binutils as a runtime dependency (only as a build dependency), hence it doesn't include the binutils version in the versionsuffix.

This is done deliberately, since the idea is that GCCcore 6.3.0 should be used together with a binutils that was built with that GCCcore 6.3.0 (https://github.com/hpcugent/easybuild-easyconfigs/blob/master/easybuild/easyconfigs/b/binutils/binutils-2.27-GCCcore-6.3.0.eb).

Whenever you are using GCCcore/6.3.0 as a toolchain, you are expected to include binutils/2.27-GCCcore-6.3.0 as a build dependency.

[JackPerdue]

What if I want to build GCCcore with dummy binutils 2.26 instead of dummy binutils 2.27? How can I distinguish them?

[JackPerdue]

And as you can see with some of my recent pull requests (meant for documentation only and not really expected to be pulled), I make a point to document my use of '-Python-2.7.12-bare' even though it is only used as a build-dependency. That's to allow for other bare Pythons using GCCcore.

And, yes, I did it the hard way and included "binutils" in most of my 2016C/2016D attempts as a builddep. Due to iccifort's deference to HMNS and using gcccore instead of gcc, building things with GCC doesn't do much with --minimal-toolchains. If I could build with GCC and have it used by min-toolchain while using a flat MNS, that would be nice But I've adapted for now.

[boegel]

@JackPerdue You're right, we have no good way of specifying which binutils version was used as a build dep for GCCcore... I guess my question there is, why are you swapping around the binutils versions that are using to build GCCcore? In practice, which version is used shouldn't matter too much, just as long as it's recent enough?

[JackPerdue]

We are (still) in the process of deploying a new cluster based on RH7 and Intel's OmniPath Architecture with IBM's GPFS (https://hprc.tamu.edu/wiki/index.php/Terra:Intro).

We've been having issues here and there so have been trying anything that might work. In the end, we've decided to use the binutils that comes with the OS (RHEL/CentOS) to keep as closely aligned with the system provided glibc Having the binutils version in the GCCcore version(suffix?) helps in such explorations.

[boegel]

Any more details on the issues you ran into that made you switch to the OS-provided binutils @JackPerdue?

I think it's fine that you switch to the OS binutils in GCCcore as a site-specific change without changing the name. If you do want to clearly reflect that you tweaked the GCCcore easyconfig, you could include a custom versionsuffix like -binutils-OS or something?

The rule we're sticking to in the central easyconfigs repo is not to use a versionsuffix for something unless it's a runtime dep; it's mostly used as a mean to specify that a module depends on some other common module (e.g. Python), so users know early on that modules would conflict with each other.

The only real way to make it clear that something was tweaked is to hash all easyconfigs, like Spack does...

[JackPerdue]

In the end, I found that using the system (older) binutils didn't have proper support for newer AVX* extensions in the 'as' assembler. Never did reach a proper conclusion on if system binutils was more stable with OPA. In any case, I'm giving up on this for now given the release of GCCcore/6.4.0 and will just run with it for now.