PyROOT Install problem on 10.5.6 Mac w/ Python 2.5.2

I’ve been struggling with an install trying to make root from source. Any help would be great.

I installed python a long time ago with fink in /sw/bin/python/. The configure command I’m using is

That works. When I went to make, I got an error:

I tried numerous things and after much confusion I tried removing the line of code that raises the error in pyport.h (after making a backup). It didn’t barf and completed the installation the next time I tried. I booted up ipython and it can autocomplete the ROOT module name, but on attempt to import ROOT it errors:

[code]In [1]: from ROOT import *

ImportError Traceback (most recent call last)

/Users/mwoods/ in ()

/Users/mwoods/lib/ in ()
84 sys.setdlopenflags( 0x100 | 0x2 ) # RTLD_GLOBAL | RTLD_NOW
—> 86 import libPyROOT as _root
88 # reset dl flags if needed

ImportError: No module named libPyROOT
Any ideas as to what is going on or how to fix it or where my installation is going wrong?


the most likely cause of a “no module named libPyROOT” is that $ROOTSYS/lib (the directory where libPyROOT is located) is not available through $PYTHONPATH. Given that this is a newer mac, another problem can be that the build is 32b and the package is 64b (or vice versa).


One of the lines from my .profile is:

So that looks ok. There were inclinations I had about the 32b/64b problems, but I do not know how to go about remedying them. Is “the build” and “the package” python and root respectively? Could you recommend a next step? Thanks for the help. I feel a bit lost in my infantile attempts at troubleshooting sometimes.


sorry, that was indeed not all that clear, but which is which shouldn’t matter, since the mismatch can be either way.

Not a Mac expert here, but I think one can see with “otool -f” what arch are supported by a binary, so if you can look at the result of that command on the python binary and on

One problem that I know of on the Mac, is that it ships with a python that supports 32b only. Building ROOT out-of-the-box will select 64b on a 64b machine. That combination would give a mismatch. You wrote that you use think; I don’t know what fink delivers.

Just to be sure, though, can you verify echo $PYTHONPATH on your shell? In case something resets it after your .profile has run.


I’ve encountered the same problem on a MacBook running Mac OS X 10.5.7. Has this issue been resolved yet? Thanks!


not sure about the previous author, but I do have a newer Mac these days, so I might be able to reproduce. Are the problems you encounter exactly alike? E.g. do you also have python from fink, and are you running ipython?


I left PyROOT in the dust and started to learn with C++ instead. I’ve recently reinstalled python from source (not fink, v2.6.2) to address a different problem. I’m getting some time off in a week or so and I’ll be reattempting this all then. I’ll post something if it works and what I’m now running.


just (finally) installed ROOT on my new MacBook, and works out-of-the-box …

Any more specific error messages?


I have a similar problem when building ROOT from source. The build dies with the #error “LONG_BIT definition…” problem.

Incidentally, this all came about because I want to use fftw and was rebuilding ROOT from source after compiling fftw3.

Here is my setup and subsequent errors:

$ uname -a
Darwin shift.local 9.7.0 Darwin Kernel Version 9.7.0: Tue Mar 31 22:52:17 PDT 2009; root:xnu-1228.12.14~1/RELEASE_I386 i386

Setting up fftw3 (following suggestions at: … oot-source)

./configure CFLAGS=-m64 --with-pic
sudo make install

Building ROOT

./configure --enable-roofit --enable-fftw3 --with-fftw3-incdir=/usr/local/include --with-fftw3-libdir=/usr/local/lib
… lots of output ending with the following error …
bin/rmkdepend -R -fpyroot/src/Adapters.d -Y -w 1000 – -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Iinclude -D_REENTRANT -pthread -DPYROOT_USE_REFLEX -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -D__cplusplus – pyroot/src/Adapters.cxx
g++ -O2 -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -Iinclude -D_REENTRANT -pthread -DPYROOT_USE_REFLEX -I/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5 -o pyroot/src/Adapters.o -c pyroot/src/Adapters.cxx
In file included from /Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/Python.h:57,
from pyroot/src/PyROOT.h:38,
from pyroot/src/Adapters.cxx:2:
/Library/Frameworks/Python.framework/Versions/2.5/include/python2.5/pyport.h:730:2: error: #error "LONG_BIT definition appears wrong for platform (bad gcc/glibc config?)."
make: *** [pyroot/src/Adapters.o] Error 1

Looking into python:

otool -f /Library/Frameworks/Python.framework/Versions/2.5/bin/python2.5
Fat headers
fat_magic 0xcafebabe
nfat_arch 2
architecture 0
cputype 7
cpusubtype 3
capabilities 0x0
offset 4096
size 13208
align 2^12 (4096)
architecture 1
cputype 18
cpusubtype 0
capabilities 0x0
offset 20480
size 13828
align 2^12 (4096)

I tried running otool on, but couldn’t find it:
In my ROOT directory,

ls lib/ | grep -i py
returns nothing.

Any help would be greatly appreciated!

Thank you,


not sure, my Mac is at home (and anyway, I haven’t experienced this problem on it yet), so in the mean time, google comes up with:

[quote]For MacOS X 10.5 (Leopard), the GNU compilers provided with the operating system are capable of producing fat binaries with all architectures, and the version of Python supplied with the operating system is also compatible with being used under all architectures. If however you installed MacPorts versions of the GNU C compilers and of Python, especially if you inherited those tools from an upgrade of Tiger to Leopard, you may run into problems with the tools not being able to produce fat binaries for all architectures.

One way this may manifest is in the form of the compile time error:

error: #error “LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).”

If this occurs, you would ideally upgrade your MacPorts versions of the GNU compiler and Python to more recent versions which are capable of being used to produce fat binaries for multiple architectures. If you cannot do this, then you should edit the ‘Makefile’ generated by the mod_wsgi ‘configure’ script and remove references to additional architectures, leaving only that for your own behind.

CFLAGS = -Wc,’-arch ppc7400’
LDFLAGS = -arch ppc7400 …

The ‘…’ should be the existing flags in LDFLAGS following the architecture flags.

Note that the error:

error: #error “LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).”

may also be due to the version of the Python framework being used not having being configured and compiled with support for 64 bit architectures. [/quote]
Does any of that describe your setup?


This may be the problem. I’ll investigate.


I have the same problem on a SLC5 machine.

/users/adotti/sw/python/2.5.4/slc5-x86_64-gcc41/Include/pyport.h:761:2: error: #error “LONG_BIT definition appears wrong for platform (bad gcc/glibc config?).”

I am using the default SLC5 compiler:
gcc --version
gcc (GCC) 4.1.2 20080704 (Red Hat 4.1.2-46)

I have installed and compiled Python 2.5, the architecture is 64 bits:
objdump -a libpython2.5.a | head
In archive libpython2.5.a:
getbuildinfo.o: file format elf64-x86-64
rw-r–r-- 1737/1196 7952 Oct 30 18:04 2009 getbuildinfo.o

Tried to compile ROOT with:
./configure --with-python-incdir=/users/adotti/sw/python/2.5.4/slc5-x86_64-gcc41/Include --with-python-libdir=/users/adotti/sw/python/2.5.4/slc5-x86_64-gcc41 --prefix=$ROOTSYS

Thus it seems that the problem is with Python 2.5.4.
Any suggestion?



unrelated, but the configure script looks for the .so library, not the .a. Using the .a as part of leads to probems when calling python from CINT otherwise.

What does the startup prompt of python tell you in terms of gcc version used?