How to build ROOT 6 on Scientific Linux

ROOT
1

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?

Cheers,
E.G.

2

Define CC and CXX environment variables to point to the new installed compiler before invoking cmake.

3

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).

$ export PYTHON_LIBRARY=/opt/rh/python27/root/usr/lib64
$ export PYTHON_INCLUDE_DIR=/opt/rh/python27/root/usr/include/python2.7
$ export PYTHON_EXECUTABLE=/opt/rh/python27/root/usr/bin/python2.7
$ cmake ../ROOT -DCMAKE_CXX_COMPILER=/opt/rh/devtoolset-2/root/usr/bin/g++ -DCM    AKE_C_COMPILER=/opt/rh/devtoolset-2/root/usr/bin/gcc -DCMAKE_LINKER=/opt/rh/dev    toolset-2/root/usr/bin/ld -DCMAKE_INSTALL_PREFIX=../ROOT_install

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
4

Hi,
does the same error occur if you compile after typing:
scl enable devtoolset-2 bash?
Or after sourcing the file /opt/rh/devtoolset-2/enable?

You can also try installing devtoolset-3

Cheers,
Matteo

5

Yes, in fact I have

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
6

I had a similar problem with a MC generator, I’ve solved exporting those variables:

export LD_LIBRARY_PATH=/opt/rh/devtoolset-3/root/usr/lib/gcc/x86_64-redhat-linux/4.9.1/:$LD_LIBRARY_PATH
export PATH=/opt/rh/devtoolset-3/root/usr/bin/:$PATH

ofc they refer to devtoolset-3. Idk if this can resolve your problem

7

Doesn’t seem to work for me

8

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”, …).

9

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?

*** Break *** segmentation violation[/code]

10

Hi,

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.

Cheers, Axel.

11

I see, thanks for the info!

Marking this as solved

12

Hi all,

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).

Thanks,
Matteo
cmake_build_attempt_with_devtoolset3gcc492_output.txt (140 KB)
cmake_attempt_with_devtoolset3gcc492_output.txt (19.3 KB)