PyROOT, Python2.5 from AFS

I am trying to get PyRoot working on a SLC3 machine here at CERN.
I am using the folowing script to setup my enviroment

export ROOTSYS=/afs/
export PYTHONDIR=/afs/

But when I import ROOT I get

(pcata007) /data/commissioning/team5/dqsummarydata> source                                    
(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/", line 83, in <module>
    import libPyROOT as _root
ImportError: 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
I have tried several other combinations of prebuilds for AFS


FYI, Root 5.17.04 has been built with Python 2.4.2



I dont understand why python is even looking for

libPyROOT is linked with libpythonx.y to allow easy autoloading into CINT (for the TPython class etc.). Of course, it needs as it was built against the C-API of p2.4.

You could put a local symlink from to, 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 to
I am certain that that would work for my needs, but how do I do that when is on AFS? Could I link to the Python main directory on AFS and then link /path/to/my/Python/directory/link/lib/

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).


Just put it anywhere early in LD_LIBRARY_PATH and that should do the trick.


If you have/get to a better solution, please share! :slight_smile:


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?

Thanks for all of your help.

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.

Further info:

[Satchel root]$ otool -L /usr/local/root/lib/root/ /usr/local/root/lib/root/ /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)

From email:

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.

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!

Thanks very much,


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”).

I’d be happy if anyone shared her/his opinion.


Hi Duc,

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 for it to work.

I’m working on having this all distutils based …



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.

I’ll incorporate this in the configure tool.