Hello,
I tried to compile ROOT’s master branch on a virtual machine mounting SLC6. The OS doesn’t provide a version of gcc with support for c++11 out of the box, so I installed the devtoolkit and python2.7 as per here.
ROOT seems to compile correctly using the g++ version contained in the devtoolkit, but some c++11 features seem to be broken. For example move-constructing a string causes a segfault.
Is there a standard procedure to build and use ROOT on Scientific Linux machines that do not have access to AFS?
These are the steps I used to build ROOT on a SLC6 virtual machine after installing devtoolkit and python2.7 (I didn’t set C and CXX but I passed the right paths to cmake which should be the same if I’m not mistaken. CMakeCache.txt confirms that CMake is using the new compilers).
ROOT compiles without errors, but I encounter the following problem running it:
$ root -b -l
root [0] std::string a = "hello"
(std::string &) "hello"[4]
root [1] std::string b = std::move(a)
IncrementalExecutor::executeFunction: symbol '_ZNSsC1EOSs' unresolved while linking function '_GLOBAL__sub_I_cling_module_9'!
You are probably missing the definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(std::string&&)
Maybe you need to load the corresponding shared library?
*** Break *** segmentation violation
source /opt/rh/devtoolset-2/enable
source /opt/rh/python27/enable
in /etc/profile, so every shell has the devtoolset enabled and g++ --version shows that gcc 4.8.2 is in use.
So even if I didn’t mention these commands in my previous post they were there.
EDIT:
I should also mention that I can compile and run ROOT on lxplus with a similar procedure, using the version of gcc available on afs instead of the one in devtoolkit. The steps are
lxplus$ source /afs/cern.ch/sw/lcg/external/gcc/4.8/x86_64-slc6/setup.sh
lxplus$ export PYTHON_LIBRARY=/afs/cern.ch/sw/lcg/external/Python/2.7.3/x86_64-slc6-gcc48-opt/lib
lxplus$ export PYTHON_INCLUDE_DIR=/afs/cern.ch/sw/lcg/external/Python/2.7.3/x86_64-slc6-gcc48-opt/include/python2.7
lxplus$ export PYTHON_EXECUTABLE=/afs/cern.ch/sw/lcg/external/Python/2.7.3/x86_64-slc6-gcc48-opt/bin/python2.7
lxplus$ cmake ../ROOT -DCMAKE_CXX_COMPILER=$(which g++) -DCMAKE_C_COMPILER=$(which gcc) -DCMAKE_INSTALL_PREFIX=../ROOT_install
###### for some reason CMake didn't pick up on the PYTHON* environment variables and complains python2.7 is not installed, so I change the paths by hand in CMakeCache.txt #####
lxplus$ cmake ../ROOT -DCMAKE_CXX_COMPILER=$(which g++) -DCMAKE_C_COMPILER=$(which gcc) -DCMAKE_INSTALL_PREFIX=../ROOT_install
lxplus$ make install
I think what happens is the following.
You put “source /opt/rh/…enable” into the “/etc/profile”. These “rh” scripts will probably modify the “LD_LIBRARY_PATH”, but these changes will be removed by the “Linux security” when your login shell is started.
I think you need to put all these “source …” commands into your own profile (i.e. something like “${HOME}/.profile”, “${HOME}/.bash_profile”, “${HOME}/.bash_login”, “${HOME}/.bashrc”, …).
Hello Wile,
I just tried to recompile ROOT from scratch (deleting the previous build) after adding
source /opt/rh/devtoolset-2/enable
source /opt/rh/python27/enableto my ~/.bashrc and my ~/.profile.
CMake does not complain (and I’m still calling it with the -DCMAKE_CXX_COMPILER flag to make it use the right compiler) and make runs without errors.
When I run an interactive session I still incur into segmentation faults when using c++11 features like move. For example: [code]root [0] std::string a(“hello”)
root [1] std::string b = std::move(a)
IncrementalExecutor::executeFunction: symbol ‘_ZNSsC1EOSs’ unresolved while linking function ‘_GLOBAL__sub_I_cling_module_9’!
You are probably missing the definition of std::basic_string<char, std::char_traits, std::allocator >::basic_string(std::string&&)
Maybe you need to load the corresponding shared library?
ROOT does not work with devtoolset. See sft.its.cern.ch/jira/browse/ROOT-6207 for why. If you have afs, use GCC provided by sourcing /afs/cern.ch/sw/lcg/external/gcc/4.9/x86_64-slc6/setup.sh - that’s a complete GCC.
I add to this thread (let me know if I should open another one with the appropriate subject) to ask if the same issue extends also to CERN Centos 7.1 & devtoolset-3, in this case to have C++14 on this platform.
I do not see the reported error e.g. with std::move(), however in this case the original gcc (v4.8.3) is already supporting c++11, and the extra step with gcc v4.9.2 (provided by devtoolset-3) is just to have the extra C++14 stuff. I have also tried several C++14 features (make_unique, generic lambdas) even if just since few weeks and for small tests. It seems to work as expected. Maybe you can suggest some more aimed test.
Please note that I managed to compile ROOT (v6.05.03) only using the “configure ; make” method, because the recommended method with CMake fails the compilation when it enconters the experimental string_view (I attached also the full output):
[...]
Scanning dependencies of target G__IO
[ 32%] Generating G__IO.cxx, ../../lib/libRIO.rootmap
In file included from input_line_9:6:
In file included from /tmp/malfonsi/root_builddir/include/TLockFile.h:19:
In file included from /tmp/malfonsi/root_builddir/include/TString.h:41:
In file included from /tmp/malfonsi/root_builddir/include/RStringView.h:24:
In file included from /opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/experimental/string_view:39:
/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.2/../../../../include/c++/4.9.2/bits/c++14_warning.h:32:2: error: This file requires compiler and library support for the forthcoming ISO C++ 2014 standard. This support is currently experimental, and must be enabled with the -std=c++1y or -std=gnu++1y compiler options.
#error This file requires compiler and library support for the forthcoming \
^
[...etc...etc...]
With the “configure; make” method the “ROOT builtin” version of string_view is preferred over the one coming from gcc4.9.2, and I can effectively use string_view objects within ROOT without errors. (I tried to “hack” RConfigure.h before “cmake . --build” to “suggest” the use of the “builtin” string_view, but it did not work as well).