in my opinion I would not include gcc5 in a toolchain which should be considered as "stable". Many developers haven't tried gcc5 yet so I think we would hit many new issues when trying to compile applications which have never been compiled with gcc5. For me in the bioinformatics field is a totally no go. I would stay by now with gcc4 in the foss toolchain and provide gcc5 as a different toolchain ( maybe foss/2016.02 ?) for those who need it or want to test it.
Anyway I am even more conservative and I am now planning my upgrade from goolf/1.4.10 to goolf/1.7.20 so feel free to ignore my comments if you enjoy being in the bleeding edge :P my two cents. 2016-01-14 1:18 GMT+01:00 Fotis Georgatos <[email protected]>: > > Hi, > > I would side closer to Damian and Kenneth, ie. play a bit conservative, as > regards the common gcc compiler version. > IMHO, the difference in community opinion among GCC/4* or GCC/5 relates > more to if you are *supporter* or *supported*. > Let’s remind here why easyconfigs are called “examples” as opposed to > “solutions” for HPC systems! > > When you deal with many users, you need to provide an environment suitable > for multiple domains, exploiting your limited/finite time. > Compatibility issues among multiple tools such as Intel, CUDA, Matlab, PGI > and open source components, inevitably imply > a lesser common denominator. Shop your arguments from the URLs here: > https://github.com/hpcugent/easybuild-easyconfigs/pull/1294 > > fi. > If you are into Life Sciences and you do narrow MD experiments, you have > good reasons to stretch versions to greatest and latest; > however, if you require a compatibility layer with the bioinformaticians > next door, that makes it a tad more constrained. > > > From my point of view, the following dep chain must be fully supported by > upstream paths or, the generic toolchains are failing: > (Python, Boost, Perl) -> Intel compilers -> GCC ; allowing CUDA in the mix > is a bonus, for Molecular Dynamics intentions. > There is loose affinity here with Common Deps list: > https://github.com/hpcugent/easybuild-easyconfigs/issues/1689 > > My own litmus test often is a variant of > HPCBIOS_LifeSciences-20130829-goolf-1.4.10.eb & a Perl that keeps other > builds happy; > an equivalent symmetric set of builds against some recent Intel toolchain, > would be convincing: it is centrally supportable and, > sufficiently advanced for further experimentation on the user-end (we > should never claim fitness, rather a working skeleton!). > > F. > > On Jan 13, 2016, at 10:17 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. > > -- > echo "sysadmin know better bash than english" | sed s/min/mins/ \ > | sed 's/better bash/bash better/' # signal detected in a CERN forum > > > > > > > > -- Pablo Escobar López HPC systems engineer sciCORE, University of Basel SIB Swiss Institute of Bioinformatics http://scicore.unibas.ch
