Problem with root-6.08.00

ROOT
1

Dear rooters,
I have recently upgrade my root version to 6.08.00, and I am having a problem that I do not know how to solve.
Unfortunately, my analysis software is complex enough to be difficult to share it with you in this forum.
Anyway, I’ll try to explain the problem:

I build a library where all my specific code is stored (user made classes, functions, constants, etc.) .
Then I build an executable which does certain operations to some data.
From this executable a root macro is called for plotting the results.
The executable can be iterated over a certain range of time steps, that is, it repeats the same operations n-times over n-different data sources.

This functionality has been working flawlessly with previous root versions.
However, since I upgraded to root-6.08.00 I got the following error:

IncrementalExecutor::executeFunction: symbol '_ZN6PConstL2I0E' unresolved while linking [cling interface function]! You are probably missing the definition of PConst::I0 Maybe you need to load the corresponding shared library? IncrementalExecutor::executeFunction: symbol '_ZStplIcSt11char_traitsIcESaIcEESbIT_T0_T1_EOS6_PKS3_' unresolved while linking [cling interface function]! You are probably missing the definition of std::basic_string<char, std::char_traits<char>, std::allocator<char> > std::operator+<char, std::char_traits<char>, std::allocator<char> >(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&&, char const*) Maybe you need to load the corresponding shared library?

This happens when calling the root macro the n-time, with n>1.
This means that it works the first iteration, but not in subsequent iterations.
Then the macro exits not plotting anything.
The iteration driven by the executable still works (it still loop over the rest of the data range),
but the macro fails and does nothing.

Is this error familiar to you? I have tried several things, but I must admit that I am lost.
The error suggests the following: "Maybe you need to load the corresponding shared library?"
but there is the following instance at the begining the macro:
gSystem->Load(“libptools.so”);

where libptools.so is my software library, which is build using the following command:

Thanks in advance.

2

Hi,

I have recently upgrade my root version to 6.08.00

Which version where you using prior to that?

6.08/00 is already pretty old. I recommend you consider using v6.08/04.

Cheers,
Philippe.

3

Hi Philippe,

The last root version that worked good for me was root-6.06.08,
and this is the one that I am using right now after failing in using root-6.08.02.
I am now trying with root-6.08.04 as you suggested…

In the mean time, I would like to make the following observations in respect to these new versions of root (root-6.08.xx):

  • cmake: The configure process, driven by cmake, takes ages!
    I measured the time needed in our cluster login node (Processor (INTEL CPUs (E5-2640 v3) Operating system: CentOS Linux release 7.3.1611) -> 11:20 (yes, 11 minutes!). And this is just the configuration process not the build.
    ‘configure’ in previous root versions (root-6.06.xx) needed only 18 seconds to be completed in the same machine.
    The ‘cmake’ procedure also needs two copies of root, one for the sources and one for the build.
    (One could delete the sources after the build, but in case that you want to keep it to change something in the source you will need it again. So, in the end, I have to keep these two copies).
    I’ve always liked the simplicity of installing root by defining ROOTSYS, typing ‘configure’ and then ‘make’. This seems to not to be possible anymore. There is even a warning in ‘configure’ saying that this method is deprecated. Nevertheless I tried and I got compilation errors, so it didn’t work.

Cheers,
Alberto

4

Ok, The compilation of root-6.08.04 finished.
It needed 12 minutes using 14 processing units in parallel (cmake --build . – -j14).
So, just 1 more minute in respect to the configuration process.

root installation went fine, but I still get the same error that I reported previously in this thread:

IncrementalExecutor::executeFunction: symbol '_ZN6PConstL2I0E' unresolved while linking [cling interface function]! You are probably missing the definition of PConst::I0 Maybe you need to load the corresponding shared library?

Which is funny because PConst::I0 it is just a static const that I define in a namespace, like many others that I use. That namespace is of course included in the dictionary:

[code]#ifdef CINT

#pragma link off all global;
#pragma link off all class;
#pragma link off all function;

#pragma link C++ nestedclasses;
#pragma link C++ nestedtypedefs;

#pragma link C++ namespace PGlobals;
#pragma link C++ namespace PFunc;
#pragma link C++ namespace PConst;
#pragma link C++ namespace PUnits;
#pragma link C++ class PUnits::UnitsTable-!;
#pragma link C++ class PUnits::BestUnit-!;
#pragma link C++ function operator<<(std::ostream&, const PUnits::BestUnit&);

#pragma link C++ class PData+;
#pragma link C++ class PDataHiP+;
#pragma link C++ global gData;

#pragma link C++ class PPalette+;

#endif
[/code]

I am pretty lost here.
Cheers,
Alberto

5

That long ? … I just timed it on my machine (Mac OS 10.12.3)

$ time cmake ../roottrunk -Dall=ON

I get:

real	0m21.927s
user	0m13.771s
sys	0m6.209s

My cmake version is 3.5.2

6

Yes, that long. I don’t know…
Sometimes it gets stuck (for a minute or two) when looking for installed components (libraries).

cmake 3.7.0

7

This is very strange. Never has seen this slowness before. Needs to be investigated. Cmake offers the option --trace to see the actual command that is executed. Perhaps you can stop the execution with the command that hangs. Alternatively, you can perhaps combine it with dtrace command.
Cheers, Pere

8

I have tried with the option --trace to see more about what is going on, but it didn’t really offer any useful information to me.
As I wrote previously, cmake takes a while when looking for libraries that are not present in the system. e.g.:

[code]-- Looking for Unuran
–> ~ 1 minute

– Could NOT find UNURAN (missing: UNURAN_LIBRARY UNURAN_INCLUDE_DIR)
– Unuran not found. Switching on builtin_unuran option
[…]

– Looking for Graphviz
–> ~ 1 minute

– Could NOT find GRAPHVIZ (missing: GRAPHVIZ_INCLUDE_DIR GRAPHVIZ_cdt_LIBRARY GRAPHVIZ_gvc_LIBRARY GRAPHVIZ_graph_LIBRARY GRAPHVIZ_pathplan_LIBRARY)
– Graphviz not found. Switching off gviz option
[…]

– Looking for Bonjour
–> ~ 1 minute
– Checking whether Bonjour/Avahi is supported
– Bonjour not found. Switching off bonjour option
[…] etc.
[/code]

9

Do you have the environment variable CMAKE_PREFIX_PATH containing non existing paths that induces timeouts? The standard places to look for libraries are in the system /usr, /usr/local, … Is there anything in your system that these locations will be pointing to network or remote disks?
Pere

10

CMake is also looking for libraries in LD_LIBRARY_PATH, so you must have a LD_LIBRARY_PATH pointing to AFS areas that takes very long to access. Can you try cleaning your environment?

11

Hi Mato,

This is a good guess because I actually have some afs locations in LD_LIBRARY_PATH.
Unfortunately I have also tried with LD_LIBRARY_PATH=“” and the problem persists.
Also CMAKE_PREFIX_PATH is empty.

In any case, why this is a difference in respect to the good old “configure” process?

12

Because looking for packages and libraries is delegated to cmake and it uses different set of places to look for them.

Another suspicious environment is PATH in addition to LD_LIBRARY_PATH.

You can try the following to see what really is being looked at. Create an empty directory and place a CMakeLists.txt file with

cmake_minimum_required(VERSION 3.4.3 FATAL_ERROR)
project(MyTest)
find_library(MYLIB unurun)
message("MYLIB=${YLIB}")

Then configure using

strace cmake . |& grep /lib

You will see what is being accessed from AFS