ROOT version number: v5.26.00
Type of machine: Cray XT5
Hello,
We recently managed to compile the entire ROOT package on a Cray XT5 machine
belonging to the CSCS in Manno, Switzerland. This task turned out to be very
tedious even with the use of recent gnu compilers (4.4.4). Our job runs in inter-
active sections but crashes when it is started by a scheduler. However, this problem
will be posted soon as another issue on the roottalk.
The present question is whether the different modules in ROOT can be used (compiled)
independently. We are using only the geometry package in ROOT. The
compilation of the geometry library alone would considerably simplify our job.
The geometry package depends only on libRIO, libMathCore, libCore and libCint (however a large subset of ROOT (about 20%). When you link you can link only with these libs.
You can remove the default packages when configuring (see ./configure --help)
ROOT is running with gcc4.4 on 64 bits machines. Did you find any special problem during the installation?
Thank you for the hints and sorry for the delayed answer. I will try to remove the default packages as you
suggested and hopefully this will simplify the compilation procedure. The problems during the installation on
the XT5 are manifold. Most of them are caused by a mandatory use of compiler scripts, i.e. CC instead of g++
for instance.
Furthermore, I did not figure out how to generate static libraries. Is it possible ? This would allow to address
our second problem on the Cray, namely the segmentation fault when using the job scheduler. This problem
could be investigated by means of TotalView on the Cray but on the other hand this requires a fully
static linkage of the binary.
Except script problems with the configuration, did you find compilation problems?
Did you compile with Position Independent Code option of your compiler?
You can generate one single static library libRoot.a (that includes all selected modules) with
make static
You may have to twist the Makefile to take into account your special case.
I strongly suggest to communicate your changes if you are interested to have them included into the mainstream system.
Most of the compilation problems have been resolved by using the default names {g++,gcc,gfortran}
instead of the compiler scripts {CC,cc,ftn}. According to the cray admins there are only minor differences
between them. The only remaining compilation problem is associated with the TTermManip.{h,cxx} files
which has been fixed by replacing curses with ncurses in the confing/Make.config file. So, the first
part of the problem is resolved.
Position independent code is produced by means of the -fPIC flag and I created a static library with
"make static". However, I figured out that there is no need for a static library in order to debug my code.
The debugger is needed in order to fix the segmentation fault caused by my code when it is started by
a scheduler. I am currently working together with the cray admins on that problem an I will come back to
you as soon as the position is located.
With the help of the cray admins I could properly start the debugger (including the job scheduler)
and locate the position, where the segmentation fault is generated:
filename : ./core/base/src/TEnv.cxx at line 407
code fragment : if (strcmp(gSystem->HomeDirectory(), gSystem->WorkingDirectory()))
is emitted from the ./core/base/src/TROOT.cxx file at line 1240. Obviously, when the
binary is started by means of the scheduler, the ROOT package is not able to read the
environment. The value returned by gSystem->HomeDirectory(), i.e. zero, finally causes
the segmentation fault.
Does ROOT need to have the environment available during the simulation or is it just
necessary to locate some parameter file at the beginning ? In the latter case, I will
comment out the problematic sections in the corresponding files and see if the rest
works. Contemporaneously, I will try to elaborate on that problem with the cray admins.
Finally the segmentation fault could be circumvented by simply setting the variable
ROOTENV_NO_HOME=1
Now the ROOT package is fluently compiling and running for our purposes on
the CRAY XT5. It remains to check some discrepancies with results obtained
on different architectures which are most probably not related to ROOT.