Hi everyone, Thank you very much for the feedback!
I feel there are sufficient arguments to stick with GCC(core) 4.9.3 in both foss/2016a and intel/2016a for now.
I've updated the pull requests [1, 2] accordingly (by adding the missing easyconfig files and an HPL easyconfig by means of test). An overview dependency graph (generated with eb --dep-graph) is attached; blue lines indicate build-only dependencies (thanks to [3]).
I'll do a couple more builds on top of these toolchain definitions (Python, Perl, OpenFOAM, ...), but I don't expect any major issues to pop up which would block us going through with what we have now, so the 2016a toolchain PRs should get merged very soon, and thus will be part of the upcoming EasyBuild v2.6.0 release.
I'll also look into a foss/2015.12 toolchain (basically foss/2016a with GCC 4.9.3 replaced with GCC 5.3.0), which can be used to start evaluating the issues we run into when building things with GCC 5.x.
The 2016a revision of the common toolchains is also part of the agenda for tomorrow's conf call [4], but I don't think there's much left to discuss.
regards, Kenneth [1] https://github.com/hpcugent/easybuild-easyconfigs/pull/2310 [2] https://github.com/hpcugent/easybuild-easyconfigs/pull/2311 [3] https://github.com/hpcugent/easybuild-framework/pull/1548[4] https://github.com/hpcugent/easybuild/wiki/Conference-calls#next-easybuild-conference-call
On 13/01/16 16:30, Adam Huffman wrote:
Yes, I agree with some provision for GCC5, perhaps as a separate toolchain. Cheers, AdamOn 13 Jan 2016, at 13:32, Robert Schmidt <[email protected]> wrote: I think we should definitely build a GCC5 or a foss-unstable (or bleed) toolchain so we can start to build for GCC5 and beyond. On Wed, Jan 13, 2016 at 5:18 AM Damian Alvarez <[email protected]> wrote: Another thing to consider might be CUDA. CUDA 7.5 requires GCC >4.3.4 && <4.9.2 (even though with 4.9.3 works fine). It seems you can make it work (at your own risk) with 5.X as long as you don't use C++11. However, that means that CUDA+C++11 developers will have troubles (i.e.: won't work) in EB-managed environments if we go for GCC 5.X. PGI-based toolchains might also require GCC <5.X, but I am not sure about that, the documentation is not clear on that regard. I'd suggest to at least keep GCCcore as 4.9.3. With just GCCcore being 4.9.3, the foss toolchain (with GCC 5.X) will be problematic for CUDA usage, but not so the Intel toolchain. Damian-----Original Message----- From: [email protected] [mailto:easybuild- [email protected]] On Behalf Of Kenneth Hoste Sent: Tuesday, 12. January 2016 20:42 To: [email protected] Subject: Re: [easybuild] foss/2016a and intel/2016a common toolchains On 12/01/16 15:20, Ward Poelmans wrote:On 11-01-16 21:50, Kenneth Hoste wrote:** GCC 4.9.3 vs GCC 5.3.0 ** The question here is if we stay with the latest release of GCC v4.x, which as it happens is still the same version as the one included in the 2015b toolchains, or if we make the jump to GCC 5.x. My personal feeling is that it's (still) too early to jump to GCC 5.x, and that we should stick to GCC 4.9.3 for the time being. The main reasons for this are that several Linux distributions are yet to pick up GCC 5.x as the main system compiler, and thus that there are many unknown issues that are bound to pop up left and right, and that the latest release of the Intel compilers is known not to be fully compatible yet with GCC 5.x (cfr. [4]).I feel adventurous and would suggest that we do move to GCC 5.I don't think that 'adventurous' and 'stable' go together well, the latter is part of the point of having common toolchains.The major issues are the new ABI of libstdc++ and that it defaults to c++11. If we stick the default to c++98 and avoid the ( -D_GLIBCXX_USE_CXX11_ABI=0) we should be fine.But, aren't we crippling GCC 5 then? Having to jump through hoops like this is a sign to me that we should hold of jumping to GCC 5 for now. Even if it's only for foss, not intel; I'm strongly in favor of using the same GCC version in both foss and intel, it makes things a lot easier. We have enough issues to deal with as is to get stuff built/installed.Maybe some poorly written build systems will assume that the major GCC version is always 4 but as GCC already did a couple of major version bumps, I think it will be a minor issue.I think that's the least of our worries, and something we'll have to deal with sooner or later. This is not a strong argument for sticking to 4.9.3 imho.* GCC version in foss vs intel With the GCCcore concept that was introduced in EasyBuild v2.5.0, it is possible to use a common GCC version as a base for both the foss and intel toolchains (e.g. 4.9.3), while using a different GCC version in foss (e.g. 5.3.0).What future do we see for GCCcore? I would keep it fixed at 4.9.3 for quite some time in the future. As it is a base compiler, it not a big deal that it's not the latest and greatest version?Well, since GCCcore is the base for the Intel compilers (as well as for the GCC used as main compiler in foss), moving on to whatever GCC >4 is compatible with the latest Intel compiler is important w.r.t. C++ features (and possible more in the future). So, I don't think sticking to 4.9.3 for years to come for GCCcore is going to be a good option. If you're concerned about getting GCC 5/6 to build with whatever GCC is default on the system, we can always make a small detour by specifying that GCC 4.9.3 is a build dependency of that GCC 5/6 we're after... K.------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------ Forschungszentrum Juelich GmbH 52425 Juelich Sitz der Gesellschaft: Juelich Eingetragen im Handelsregister des Amtsgerichts Dueren Nr. HR B 3498 Vorsitzender des Aufsichtsrats: MinDir Dr. Karl Eugen Huthmacher Geschaeftsfuehrung: Prof. Dr.-Ing. Wolfgang Marquardt (Vorsitzender), Karsten Beneke (stellv. Vorsitzender), Prof. Dr.-Ing. Harald Bolt, Prof. Dr. Sebastian M. Schmidt ------------------------------------------------------------------------------------------------ ------------------------------------------------------------------------------------------------The Francis Crick Institute Limited is a registered charity in England and Wales no. 1140062 and a company registered in England and Wales no. 06885462, with its registered office at 215 Euston Road, London NW1 2BE.
foss-intel-2016a.pdf
Description: Adobe PDF document
