Heads up: the OpenMPI version included in foss/2016a was bumped last
minute to 1.10.2 (was 1.10.1), cfr.
https://github.com/hpcugent/easybuild-easyconfigs/pull/2363.
I figured this was OK since the foss/2016a was merged just shortly
before, and the bump was thoroughly tested by rebuilding all easyconfigs
that were in place already in develop for foss/2016a.
regards,
Kenneth
On 19/01/16 10:04, Kenneth Hoste wrote:
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,
Adam
On 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.
