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/ROOT.py in ()
84 sys.setdlopenflags( 0x100 | 0x2 ) # RTLD_GLOBAL | RTLD_NOW
85
—> 86 import libPyROOT as _root
87
88 # reset dl flags if needed
ImportError: No module named libPyROOT
[/code]
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).
export PYTHONPATH=$ROOTSYS/lib:$PYTHONPATH
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 libPyROOT.so.
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.
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.
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:
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.
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?
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 libPyROOT.so leads to probems when calling python from CINT otherwise.
What does the startup prompt of python tell you in terms of gcc version used?