{bundle}[dummy] GCC-4.9.3-2.25: bundle of GCCcore 4.9.3 and binutils 2.25

[boegel]

requires easybuilders/easybuild-framework#1451 and easybuilders/easybuild-easyblocks#773

This sort of replaces #2108, and deals with a coupe of problems there, in particular:

• avoids building GCC twice to construct the foss toolchain; the GCC is just a bundle of GCCcore and binutils
• drop binutils from versionsuffix of GCCcore (since it's only a build dep there)
• drop -binutils-2.25 as versionsuffix for binutils-2.25; it looks stupid, and which binutils was used to build binutils with is most likely irrelevant

As opposed to #2108, these additional easyconfigs do not affect existing toolchain, in particular the 2015b ones, which are close to 'end of life', and thus should not be fiddled with.

The intention is to use the GCC/4.9.3-2.25 bundle as a base for the 2016a toolchains (#2194 will be adjusted to use it, since intel/2015.08 a likely candidate for intel/2016a).

There's a GCC/4.9.3-binutils-2.25 too, which is an actual GCC build rather than a bundle. This may be confusing right now, but since there's no GCC 4.9 or binutils update, that's the way it is.

@ocaisa, @geimer, @wpoely86: thoughts?

[hpcugentbot]

Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5252/console for more details.

Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do.

[hpcugentbot]

Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5253/console for more details.

Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do.

[hpcugentbot]

Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5254/console for more details.

Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 7 out of 7 (7 easyconfigs in this PR)
Linux centos linux 7.1.1503, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz, Python 2.7.5
See https://gist.github.com/111589ed1a1216c2c8c5 for a full test report.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 7 out of 7 (7 easyconfigs in this PR)
Linux SL 6.7, Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz, Python 2.6.6
See https://gist.github.com/54dbc3c7542ea28efb28 for a full test report.

[hpcugentbot]

Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5255/console for more details.

Please fix the reported issues by pushing additional commits to the branch corresponding with this pull request; contact @boegel if you're not sure what to do.

[wpoely86]

Looks fine, but preferably (but not possible currently), the GCCcore module is hidden (or spits out a warning that it shouldn't be loaded directly

[boegel]

Hiding a toolchain isn't possible yet, but we can add a modloadmsg?

The problem is, it will always be printed, I'm not sure we can actually detect a 'manual' load...

[hpcugentbot]

Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5265/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

[boegel]

@wpoely86: also, hiding modules is considered a site-specific choice, it shouldn't be hardcoded somewhere...

Lmod will hopefully soon allow to make modules invisible (simply not show them in module avail without having to rename them), that's the way to go imho.

[wpoely86]

Well, we create a module that never should be loaded directly by the user. That makes hiding it no longer a site specific choice.

[boegel]

@wpoely86: well, shouldn't, but they will get a GCC that works, they're just going to rely on the OS-provided binutils in that case.

The current situation is worse, where people should load GNU, rather than GCC.

Anyway, support for hiding toolchains will be added at some point, and I'm willing to have the discussion of hiding GCCcore by default then.

[ocaisa]

I don't like that you intend to use GCC as a base for iccifort, this means I can't put iccifort and GCC in the 'compiler' family since I need them both loaded at once. Is it not ok to explicitly list GCCcore and bintuils for those cases?
I guess that's a site specific choice but anyone with our case is probably not uncommon (for some software packages at least), we have the same MPI implementation for GCC and iccifort, and in that case we have a reverse race condition...whoever gets loaded last dictates which MPI gets picked up.

[boegel]

@ocaisa: you're right, I shouldn't be using GCC as a base for icc/ifort, I should be using GCCcore, since the whole point of using GCCcore is to be able to use it as a base for the intel toolchain without having GCC around as well... Thanks a lot for bringing that up.
I'll change that in #2194, #2209 and #2219 for the new intel toolchains.

Besides that, do you agree that this GCC bundle is a better approach than having two full GCC builds around for foss (which is what you're doing in #2108).

[ocaisa]

I'm happy with this. The setup is completely flexible so works in all scenarios. A bundle is fine for the use case here and the setup in the framework still gives me the freedom to build a different GCC version and use that instead...that's my target use case, GCCcore 4.9.3 for all my compilers (Intel, PGI, GCC) with the GCC version being 5.X (configured to use the old C++ ABI be default for compatbility with software installed using GCCcore).

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 7 out of 7 (7 easyconfigs in this PR)
Linux SL 6.7, Intel(R) Xeon(R) CPU E5-2670 0 @ 2.60GHz, Python 2.6.6
See https://gist.github.com/9a597457bd4e4738637a for a full test report.

[boegel]

Test report by @boegel
SUCCESS
Build succeeded for 7 out of 7 (7 easyconfigs in this PR)
Linux centos linux 7.1.1503, Intel(R) Xeon(R) CPU E5-2680 v3 @ 2.50GHz, Python 2.7.5
See https://gist.github.com/9690b61507d70dd1f752 for a full test report.

[hpcugentbot]

Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5297/console for more details).

This pull request is now ready for review/testing.

Please try and find someone who can tackle this; contact @boegel if you're not sure what to do.

[boegel]

As agreed with @ocaisa (who created #2108) and @geimer, I'm merging this one rather than #2108, for a number of reasons:

• doesn't affect existing 2015b toolchains (which are sort of end-of-life)
• avoids building/installing GCC twice to install the foss toolchain
  • this is overkill since both the GCC and GCCcore are using the same GCC version
  • it's still possible to build GCC version B on top of GCC version A (typically with B > A), taking into account ABI compatibility issues as discussed in GCCcore #2108 (comment), which is a valid use case
• shorter versionsuffixes

Thanks for the review @wpoely86, and @ocaisa and @geimer for the feedback!