Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5610/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.

reading up on this I noticed the world is still heavily adapting to the 5.x ABI changes,
I see only Arch linux took the brave step to be the first to switch to the new ABI
(https://www.archlinux.org/news/c-abi-change/ )
And they are still running into huge issues (e.g. llvm is not compatible with this ABI yet)
https://llvm.org/bugs/show_bug.cgi?id=23529
http://reviews.llvm.org/D12834

so, I'm in favour of sticking with the 4.x for a while, until this fleshes out.
since packages that need the c(++)11 features seem to be pretty sparse (and can be built with a gcc/5.x. just fine)

As far as I understand it, we shouldn't have any trouble as long as we stick with the old ABI (-D_GLIBCXX_USE_CXX11_ABI=0) and set the default C++ to c++98. It's the only major breaking point of GCC 5.x.
Some configure script might have issues that the major version number changes but as this is not the first time, it doubt it will be many. And I doubt even more that they will be fixed by next year.

@wpoely86 but then what compiler will we use to compile applications that do need the c++11 features?

As discussed, C++11 with GCC will keep on working as long as -std=c++11 is passed as an argument. It's only the couple of features that need the new ABI that don't work (but can work when the define is dropped).

@wpoely86: to me, that's another reason for sticking to GCC 4.9.3 for now, since we won't miss anything major for the time being...

The main requirement for me in compatibility with the Intel compilers, since I'm strongly in favour of using the same GCC in both foss and intel. Mixing versions is just to make things needlessly complicated, for now.

We can revisit things when there are compelling reasons to switch to GCC 5/6, but for now, I see none.

Easyconfigs unit test suite FAILed.

See https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5674/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.

Easyconfigs unit test suite PASSed (see https://jenkins1.ugent.be/job/easybuild-easyconfigs-pr-builder/5675/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.

Test report by @boegel
SUCCESS
Build succeeded for 9 out of 9 (9 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/cebc14cef226e712cc3d for a full test report.

Test report by @boegel
SUCCESS
Build succeeded for 9 out of 9 (9 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/971f99733b80a7077348 for a full test report.

definition finalised as discussed via EB mailing list and last conf call

tested with Python 2.7.11 (#2352), Perl 5.20.3 (#2354), Boost 1.59.0 (#2356), CMake 3.4.1 (#2355) and Bison 3.0.4 + M4 1.4.17 + flex 2.5.39/2.6.0 (#2353)

going in!