Dynamic loading dependencies issue

chamont · April 4, 2012, 9:13am

Hi Rooters,

I have problems dynamically loading two libraries. The second one require the first one, but for some reason ROOT does not seem to recognise that the needed library is already here, and then I guess it searches it in usual paths and does not find it, since the path where stay the libraries is not registered. The basic fact is that I have first loaded the needed library, and ROOT should not search a new one. I use ROOT 5.26, the code has proved to work at least until 5.18. A simplified example :

 [b]root [0] .L  /.../GlastRelease/17-35-24-rp03/lib/libcommonRootData.so[/b]
 .L /.../GlastRelease/17-35-24-rp03/lib/libcommonRootData.so
 [b]root [1] .L /.../GlastRelease/17-35-24-rp03/lib/libreconRootData.so[/b]
 dlopen error: libcommonRootData.so: cannot open shared object file: No such file or directory
 Load Error: Failed to load Dynamic link library /.../GlastRelease/17-35-24-rp03/lib/libreconRootData.so
 *** Interpreter error recovered ***

Any idea ?

chamont · April 4, 2012, 6:32pm

A rootmap story ?

pcanal · April 4, 2012, 8:28pm

Hi David,

It is also plausible that it is a deficiency in the detection of which library has already been loaded.
Indeed having the 1st library in the 2nd library’s rootmap would be also needed for this to appear.

The easiest workaround seems to be to add the end directory in the LD_LIBRARY_PATH.

Cheers,
Philippe.

chamont · April 5, 2012, 3:15pm

The difficulty is that those directories are established at runtime.
I will look if there is some sort of internal ROOT equivalent to LD_LIBRARY_PATH which I can extend dynamically. If no, I have a big problem

pcanal · April 5, 2012, 3:18pm

Hi,

You can use gSystem->Setenv to manipulate LD_LIBRARY_PATH at run-time.

Cheers,
Philippe.

PS. Another option to upgrade to a more recent version of ROOT

chamont · April 5, 2012, 3:54pm

It sounds like the way to go.

chamont · April 5, 2012, 10:21pm

Investigation goes on…
Using gSystem->SetDynamicPath() or gSystem->Setenv() at runtime does not work.
Setting LD_LIBRARY_PATH before running does work.
The problem seems to have apparead when Fermi moved from CMT to SCONS building tool for its libraries.

pcanal · April 6, 2012, 9:01pm

Hi David,

What doesldd /.../GlastRelease/17-35-24-rp03/lib/libreconRootData.so print?

Cheers,
Philippe.

chamont · April 6, 2012, 9:54pm

    linux-gate.so.1 =>  (0x00a3e000)
    libcommonRootData.so => not found
    libTree.so => not found
    libNet.so => not found
    libGpad.so => not found
    libGraf.so => not found
    libRIO.so => not found
    libHist.so => not found
    libPhysics.so => not found
    libMatrix.so => not found
    libCore.so => not found
    libCint.so => not found
    libMathCore.so => not found
    libThread.so => not found
    libpthread.so.0 => /lib/libpthread.so.0 (0x00daa000)
    libdl.so.2 => /lib/libdl.so.2 (0x00a9d000)
    libfacilities.so => not found
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00110000)
    libm.so.6 => /lib/libm.so.6 (0x00c7f000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x0090e000)
    libc.so.6 => /lib/libc.so.6 (0x00356000)
    /lib/ld-linux.so.2 (0x00964000)

pcanal · April 7, 2012, 1:16am

Hi,

libcommonRootData.so => not foundThis really means that you must have the directory in your LD_LIBRARY_PATH by ‘construction’ of the library (i.e. I guess this is a new requirement for your environment due to the switch to scons). I am not quite sure why the explicit previously loading does not satisfy dlopen in this case (but it is plausible it is a deficiency in v5.26).

Philippe.

chamont · April 7, 2012, 3:27pm

Thanks for the diagnostic, philippe.
I will reinvestigate when Fermi move from 5.26.

noeldawe · October 17, 2012, 9:38am

[quote=“chamont”]Investigation goes on…
Using gSystem->SetDynamicPath() or gSystem->Setenv() at runtime does not work.
Setting LD_LIBRARY_PATH before running does work.
The problem seems to have apparead when Fermi moved from CMT to SCONS building tool for its libraries.[/quote]

Same issue here (ROOT 5.30). SetDynamicPath and Setenv do not work. Setenv not working makes sense since LD_LIBRARY_PATH is already read by the time the program starts and changes to it are ignored. I see no way of loading the libraries dynamically at runtime without having set LD_LIBRARY_PATH beforehand. Any more ideas?

chamont · October 17, 2012, 10:03am

I have not re-investigated recently, but as far as I know, that’ s always an unsolved issue for us.

noeldawe · October 17, 2012, 10:53am

My solution for now is to not specify the library dependencies to the linker but instead write out a simple file alongside every library listing the libraries it depends on. It is known at runtime where to locate the other libraries and a function recursively loads all the dependencies before loading each library. This seems to work fine.

A few months ago I was playing with SCons but have since settled on using waf. The waf wscript compiles a bunch of packages that include LinkDefs into libraries that are loadable in a Python environment. “waf install” automatically builds a Python package with subpackages for each library. Simply importing a specific subpackage takes care of gSystem.Load-ing the associated library and dependencies.