(pcata007) /data/commissioning/team5/dqsummarydata> source setup.sh
(pcata007) /data/commissioning/team5/dqsummarydata> python
Python 2.5 (r25:51908, May 16 2007, 17:06:03)
[GCC 3.2.3 20030502 (Red Hat Linux 3.2.3-58)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import ROOT
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/afs/cern.ch/sw/lcg/external/root/5.17.04/slc3_ia32_gcc323/root/lib/ROOT.py", line 83, in <module>
import libPyROOT as _root
ImportError: libpython2.4.so.1.0: cannot open shared object file: No such file or directory
>>>
I am assuming that ROOT v5.17.04 is built against Python 2.5.xx
I dont understand why python is even looking for libpython2.4.so.1.0
I have tried several other combinations of prebuilds for AFS
I dont understand why python is even looking for libpython2.4.so.1.0
libPyROOT is linked with libpythonx.y to allow easy autoloading into CINT (for the TPython class etc.). Of course, it needs python2.4.so as it was built against the C-API of p2.4.
You could put a local symlink from libpython2.4.so to libpython2.5.so, which usually works ok on Linux (minus a nasty warning message; other than that, python APIs typically only change in a major way across 2 releases), but you’d have to restrict to 32b only as 2.5 is the first 64b capable python release.
You could put a local symlink from libpython2.4.so to libpython2.5.so
I am certain that that would work for my needs, but how do I do that when libpython1.4.so is on AFS? Could I link to the Python main directory on AFS and then link /path/to/my/Python/directory/link/lib/libpython2.4.so?
Is there simply an AFS binary of ROOT that is, in fact, built against Python2.5?
In fact, I only need to call the ROOT libraries inside of Python and not vice versa. More simply all I need to do is convert TH1?s and TGraphs from ROOT TFiles into python shevles (using protocol 2 which is only available in 2.5).
I am doing something very task specific. I think I will bite the bullet and use 2.4 to keep things clean until a Python2.5 version of ROOT is put on AFS. Any reason why Numpy is not available from the SLC repos?
The module you linked to pickles objects TO ROOT files. I am trying to convert from ROOT objects to arrays and pickle to python shelves. I attempted to use ROOT for a year and found it too slow to develop and debug (mostly due to the overall style). However, I must still deal with data stored as ROOT objects on *.root files.
Ideally, I would like a way to extract data from the most commonly used objects without importing ROOT though this seems nearly impossible. For now I try to simply convert relevant data from TGraphs and Histograms into numpy arrays and shelve the data.
[Satchel root]$ otool -L /usr/local/root/lib/root/libPyROOT.so
/usr/local/root/lib/root/libPyROOT.so:
/usr/local/root/lib/root/libPyROOT.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)
/usr/local/root/lib/root/libCore.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libCint.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libRIO.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libNet.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libHist.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libGraf.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libGraf3d.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libGpad.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libTree.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libMatrix.dylib (compatibility version 0.0.0, current version 0.0.0)
/usr/local/root/lib/root/libReflex.dylib (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.5/Python (compatibility version 2.5.0, current version 2.5.1)
/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)
No, it’s still the same as every other python/macosx we’ve had so far: an
issue with the local install. There are two python interpreters loaded: the
old one and the new one. Either because either build (python or root) is
dragging in the other, or because the local environment picks up the other.
So, also check LD_LIBRARY_PATH and DYLD_LIBRARY_PATH?
[/quote]
Well, you’re absolutely right (of course). I went to my bog-standard Leopard install, looked at where it was picking up python, and used the same thing in my machine. Lo and behold,
[Satchel ~]$ /System/Library/Frameworks/Python.framework/Versions/Current/bin/python
Python 2.5.1 (r251:54863, Oct 5 2007, 21:08:09)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
from ROOT import *
How do I go about uninstalling my extraneous (and now very irritating) Python 2.5 installation?
Curses! How many HOURS did I waste rebuilding ROOT three times on a 1.5 GHz PPC! Aaarrrgh!
Hi,
so I just ran into the same problems with root and Leopard and yes, starting the python version that comes with Leopard solves the problem.
But I am using fink to install ipython (extremly useful), and it comes with its own python version. Hence if I start ipython I cannot import ROOT and there is no ipython shipped with Leopard.
So simple question, how can I compile ROOT so that it is linked to the python version from fink? Does anyone even know how to tell fink to link to the right version (using the “fink rebuild root5 command”).
by providing the locations of the include and library paths, see “configure --help | grep python” for the variable names. I haven’t tried this since p2.3 coming from Fink on MacOS 10.3, at which point I had to remove linking with libpython2.3.so for it to work.
so finally figured out what is wrong with the fink install: it has all python symbols in both the executable and in the linkable library, rather than simply linking the executable with the library. Then, at runtime, there are duplicate symbols. The workaround is to add “-Wl,-flat_namespace” to the linker flags when building PyROOT.
