Dlopen error after "import ROOT"

I have an issue, but maybe not, when try to load ROOT within a python session. This output shall explain then problem:

Python 2.5.1 (r251:54863, Oct  5 2007, 13:36:32) 
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
*** Custom functions and configurations loaded ***
>>> import ROOT
dlopen error: /home/volpig/downloads/root_cvs/root/lib/libThread.so: undefined symbol: _ZNK7TObject7DoErrorEiPKcS1_Pc
Load Error: Failed to load Dynamic link library /home/volpig/downloads/root_cvs/root/lib/libThread.so
Error: cannot open file "libPyROOT.so"  :0:
Error: cannot open file "libPyROOT.so"  :0:
Error: cannot open file "libPyROOT.so"  :0:
Error: cannot open file "libPyROOT.so"  :0:
Error: cannot open file "libPyROOT.so"  :0:

but after that message ROOT library in python works well: histograms, graphs…

the libThread.so is load without problem a standard interactive ROOT session.



that is a decidedly odd result … _ZNK7TObject7DoErrorEiPKcS1_Pc is part of libCore.so, which libPyROOT.so is linked with. OTOH, libPyROOT.so is not linked with libThread.so (at least not that I’m aware of, and not on my box).

Could you please provide the results of ldd $ROOTSYS/lib/libPyROOT.so ? Thanks.


Hi Wim,
this is the ldd output that you requested

        linux-gate.so.1 =>  (0xffffe000)
        libCore.so => /home/volpig/downloads/root_cvs/root/lib/libCore.so (0xb7818000)
        libCint.so => /home/volpig/downloads/root_cvs/root/lib/libCint.so (0xb723e000)
        libRIO.so => /home/volpig/downloads/root_cvs/root/lib/libRIO.so (0xb70e1000)
        libNet.so => /home/volpig/downloads/root_cvs/root/lib/libNet.so (0xb6fdf000)
        libHist.so => /home/volpig/downloads/root_cvs/root/lib/libHist.so (0xb6d04000)
        libGraf.so => /home/volpig/downloads/root_cvs/root/lib/libGraf.so (0xb6ac6000)
        libGraf3d.so => /home/volpig/downloads/root_cvs/root/lib/libGraf3d.so (0xb69bc000)
        libGpad.so => /home/volpig/downloads/root_cvs/root/lib/libGpad.so (0xb68ef000)
        libTree.so => /home/volpig/downloads/root_cvs/root/lib/libTree.so (0xb6724000)
        libMatrix.so => /home/volpig/downloads/root_cvs/root/lib/libMatrix.so (0xb64d8000)
        libReflex.so => /home/volpig/downloads/root_cvs/root/lib/libReflex.so (0xb6428000)
        libdl.so.2 => /lib/tls/i686/cmov/libdl.so.2 (0xb640e000)
        libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0xb62d5000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xb61e2000)
        libm.so.6 => /lib/tls/i686/cmov/libm.so.6 (0xb61bd000)
        libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xb61b2000)
        libpthread.so.0 => /lib/tls/i686/cmov/libpthread.so.0 (0xb619a000)
        libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb6050000)
        libz.so.1 => /usr/lib/libz.so.1 (0xb603a000)
        libpcre.so.3 => /usr/lib/libpcre.so.3 (0xb6013000)
        libcrypt.so.1 => /lib/tls/i686/cmov/libcrypt.so.1 (0xb5fe5000)
        libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0xb5f75000)
        /lib/ld-linux.so.2 (0x80000000)
        libutil.so.1 => /lib/tls/i686/cmov/libutil.so.1 (0xb5f71000)

I’m using the development version but I experienced this problem also in the 5.18.


this is too odd. I can’t see where libThread.so comes into play, nor why its loading would be a problem given that libCore.so is properly linked in.

Can you use the environment variable LD_DEBUG=files to further localize the problem (or LD_DEBUG=symbols although that will give a huge output)? We need to find which library is really bringing in libThread.so.


It seems that libCint.so requires libThread.so:

7269: file=/home/volpig/downloads/root_cvs/root/lib/libThread.so [0]; needed by /home/volpig/downloads/root_cvs/root/lib/libCint.so [0]

I attached the complete log files.

As I said the versiont that I’m using is 5.19/01, on a Ubuntu 7.10 installation, python version 2.5.1, gcc 4.1.3. A didn’t have any problem in interactive sessions or standalone programs linked to ROOT.
py_ROOT.txt (21.7 KB)


this is too odd. So, libRIO.so and libThread.so are being loaded as if they are dictionary files. Also, the message:[quote]Error: cannot open file “libPyROOT.so” :0:[/quote](as well as the other ones) comes from CINT and I don’t see what business it has, loading PyROOT.so.

Grabbing at straws here; anything happening in "*** Custom functions and configurations loaded *** " that could affect ROOT?


The part the you quoted is a python macro loaded at the login, this is the code and I don’t think can be related with the ROOT problem but… to ensure this is the code:

[code]from math import *

def errsum(listerr) :
sum = .0
for v in listerr:
sum += v**2
return sqrt(sum)

def errprop_prod(v1,v2) :
res = [0,[]]
res[0] = v1[0]*v2[0]
for i in range(len(v1[1])):
res[1].append( sqrt((v1[i]*v2[0])**2+(v1[0]*v2[i])**2) )
return res

def errprop_div(v1,v2) :
res = [0,[]]
res[0] = v1[0]/v2[0]
for i in range(len(v1[1])):
return res

print “*** Custom functions and configurations loaded ***”

and disabling this startup script the behavior doesn’t change.

Any idea where to find the possible reason. I also want to repeat that despite this error the python modules works well.

thanks for the help.


no, I’m a bit at a loss as to where to start. Three more things that can be checked: 1) ldd $ROOTSYS/lib/libCint.so should not be linked against libThread.so. 2) in $ROOTSYS/lib/*.rootmap, which would tickle autoloading of libThread, it only shows up for libHTML, libProofPlayer, libProof (and of course libThread) in my installation. Since I see none of these libs auto-loaded in your case, there should be no other rootmap files referencing libThread. And 3) do an “import libPyROOT” and see whether it makes any difference.


I did the checks:

  1. it’s true, “ldd libCint.so” doesnt’t search for libThread.so

  2. a difference, in my installation libThread is linked from: libHtml, libNetx, libProofPlayer, libProof, libProofx, libThread

  3. also importing libPyROOT I received the same error

will follow my ROOT configuration:

ROOT ./configure options: --enable-mathcore --enable-mathmore --enable-minuit2 --enable-xml --enable-cintex --enable-python --enable-opengl --enable-krb5 --enable-minuit2 --enable-rfio --enable-rpath --enable-soversion --enable-unuran --enable-asimage --enable-roofit --enable-astiff --enable-asimage --disable-builtin-afterimage --disable-builtin-freetype --enable-table --enable-reflex --enable-fftw3 --disable-builtin-pcre --disable-builtin-zlib --disable-builtin-ftgl



I needed to make a small modification to the set of configure parameters for my system, but at least that results in the same .rootmap set. Not that (after looking in there) that seems to make any difference: none of the classes in there are going to be autoloaded by PyROOT.

Completely different track (that is, instead of trying to find out why libThread.so is loaded, trying to find out why it doesn’t resolve against that symbol in libCore.so): can you post the results of:import sys print sys.getdlopenflags() print sys.platform
The ROOT.py file modifies dlopenflags for linux to include RTLD_GLOBAL for the duration of “import libPyROOT”.


This is ht output you requested:

[code]Python 2.5.1 (r251:54863, Oct 5 2007, 13:36:32)
[GCC 4.1.3 20070929 (prerelease) (Ubuntu 4.1.2-16ubuntu2)] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.
*** Custom functions and configurations loaded ***

import sys
print sys.getdlopenflags()

print sys.platform


Let me know if this helps, I’m not very usual with these advanced python features and I don’t have any idea how give you more information.

Thanks again


no, it doesn’t help (in the sense that the variables are completely as expected). :stuck_out_tongue:

So, libCore.so will be opened with RTLD_GLOBAL (i.e. all symbols made available globally for resolving against by later loaded libraries), so there is no reason why the symbol would be awol when libThread is being loaded.

Sorry, none of the diagnostics fit the symptoms, and I’ve completely run out of ideas … :frowning:


Hi Wim,
after a while, to try to explore other things, I have found the reason (not obvious) why the python module in my installation give the warnings:

In my ~/.rootrc I added this line:

Unix.*.Root.UseThreads: true

while the standard value set in the $ROOTSYS/etc/system.rootrc is

Unix.*.Root.UseThreads: false

restoring the original value the warings desappeared, I’m also figure out why changed this value, but I don’t remeber the reason :stuck_out_tongue:


yes, that allows me to reproduce the problem. However, I still don’t understand it: both python and cint load all libraries with RTLD_GLOBAL flag set, but when tracing the symbol resolution, libCore is not considered for symbols when libThread is being loaded (it is for the other libs being loaded).