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.
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.
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])):
res[1].append(sqrt((v1[i]/v2[0])**2+(v1[0]*v2[i]/v2[0]**2)**2))
return res
print “*** Custom functions and configurations loaded ***”
[/code]
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.
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 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”.
[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 ***
no, it doesn’t help (in the sense that the variables are completely as expected).
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 …
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
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).