the Mac OS X build of root 5.26 doesn’t work on my fresh installation of Snow Leopard, it seems it looks for libraries in places where it shouldn’t:
[code]Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
from ROOT import *
Traceback (most recent call last):
File “”, line 1, in
File “/usr/local/root/lib/ROOT.py”, line 86, in
import libPyROOT as _root
ImportError: dlopen(/usr/local/root/lib/libPyROOT.so, 2): Library not loaded: /afs/cern.ch/sw/lcg/external/Python/2.5.4p2/osx105_ia32_gcc401/lib/Python
Referenced from: /usr/local/root/lib/libPyROOT.so
Reason: no suitable image found. Did find:
/usr/local/root/lib/Python: not a file
[/code]
I have tried to compile it but it was impossible: lots of segmentation faults and errors, it even crashes the Terminal.app.
Is there anything I am doing wrong? The problem with the precompiled binaries was also there when I was using Leopard, and only happened with 5.26, but 5.24 worked fine.
Thanks,
Albert
PS: I have read this forum’s post about PyROOT in Snow Leopard, but it’s not quite the same as this, so I decided to post a new thread instead of continuing that one…
it seems that the afs location is “hardcoded” in libROOT
albert@dc10:~$ otool -L $ROOTSYS/lib/libPyROOT.so
/usr/local/root/lib/libPyROOT.so: @rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.4) @rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libCint.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libNet.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libHist.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libGraf.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libGraf3d.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libGpad.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libMatrix.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libMathCore.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libThread.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libReflex.so (compatibility version 0.0.0, current version 0.0.0)
/afs/cern.ch/sw/lcg/external/Python/2.5.4p2/osx105_ia32_gcc401/lib/Python (compatibility version 2.5.0, current version 2.5.0)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.4.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
talking to Fons privately … setting of DYLD_LIBRARY_PATH should override the /afs path. Did you add an entry in it to point to your local Python installation? And if so, is that local Python a 32b one, or is it a 64b installation?
In addition, I notice above that it states “Python 2.6.4” but the build appears to be using “2.5.4p2”. Unlikely that the two versions will mix harmlessly …
I had DYLD_LIBRARY_PATH pointing to $ROOTSYS/lib, but I don’t think I had it pointing to my local Python installation, which is 32b by the way.
I cannot check it right now, because I have compiled the trunk (needed a bugfix for Minuit2) so I cannot test if setting DYLD_LIBRARY_PATH pointing to my local python installation fixes the issue. I’ll test and report back as soon as I can.
[code]albert@dc10:~/Desktop$ export DYLD_LIBRARY_PATH=$ROOTSYS/lib:/Library/Frameworks/Python.framework/Versions/Current:DYLD_LIBRARY_PATH
albert@dc10:~/Desktop python
Python 2.6.4 (r264:75821M, Oct 27 2009, 19:48:32)
[GCC 4.0.1 (Apple Inc. build 5493)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.