A colleague has just notice this statement on the page describing how to build ROOT from source. “C++11 is supported until ROOT v6.24: subsequent versions require at least C++14”. I’m surprised that such an important piece of information is only written there but I can’t find it mentioned in any blog posts or forum announcements. It is important because it will mean ROOT can not be built with the default compiler which comes with Centos7. I’m sure there are good reasons for making such a change, and I am aware that using containers is the way to go these days, I just wondered if there had been any consultation with the user community about it, and when is 6.26 likely to arrive?
Thanks for your post! It’s a great idea: we will have a blog post explaining what made us change the minimum C++ standard, for the first time in seven years.
We are aware of CentOS7 not supporting C++11. We are also seeing a large fraction of our Linux user base using one of these:
- EPEL on CentOS7
- anything newer than CentOS7
- cvmfs-based releases, e.g. experiments’ software stacks
Any of these options will do. Please let us know if there is a use case that cannot be covered reasonably well after we switched to C++14.
We expect to release v6.26 around the end of the year.
“EPEL on CentOS7” doesn’t seem to provide anything useful:
yum list all|grep -i gcc
Conda … really?
“anything newer than CentOS7” … have you ever succeeded to convince administrators of any batch clusters to “switch” them to a new operating system?
“cvmfs-based releases” … have you ever succeeded to convince administrators of any batch clusters to enable CVMFS for you?
(Two data-points: the ROOT conda package has ~340k+ downloads as of today. And I have not seen a batch cluster in recent years that was forcing users to use CentOS7’s system compiler, gcc 4.8.5. Even when CentOS7 was the base system, overlay environments were provided with more recent toolchains).
There is always the devtoolset … AFAIK both xrootd and eos changed the building procedure for el7 to requiring devtoolset so it should be ok … the only problem that might arise is if the toolchain becomes a runtime dependency (which xrootd and eos avoided to do so).
If a cluster admin cannot provide devtoolset/cvmfs there is always the option of a local user-side copy of such content and source the required file (which AFAIK is relative to itself so everything is relocatable)
L.E. while i cannot be considered to know the entire landscape of clusters installations, all (scientific) clusters that i heard off (with the obvious exception of HPC ones where everything is different) have the cvmfs enabled for the users.
An extract from the official “Building ROOT from source” web page:
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.