Hi,
I’m having problems running PyROOT on OS X 10.5 on an intel mac. Importing it in python gives the following error:
>>> import ROOT
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "ROOT.py", line 83, in <module>
import libPyROOT as _root
ImportError: dlopen(./libPyROOT.so, 2): no suitable image found. Did find:
./libPyROOT.so: mach-o, but wrong architecture
>>>
The default settings use the -m64 flag. Could this be the problem? I tried to compile it with macosx (instead of macosx64) as architecture but that gave me this compilation error:
gcc -O2 -pipe -W -Wall -fsigned-char -fno-common -Iinclude -DR__HAVE_CONFIG -DG__REGEXP -DG__UNIX -DG__SHAREDLIB -DG__ROOT -DG__REDIRECTIO -DG__OSFDLL -DG__STD_EXCEPTION -I. -DG__SYSTYPES_H -o cint/lib/G__c_posix.o -c cint/lib/G__c_posix.c
cint/lib/G__c_posix.c: In function 'G__posix__0_30':
cint/lib/G__c_posix.c:203: warning: passing argument 1 of 'putenv' discards qualifiers from pointer target type
cint/lib/G__c_posix.c: In function 'G__posix__0_54':
cint/lib/G__c_posix.c:348: error: too many arguments to function 'setpgrp'
make: *** [cint/lib/G__c_posix.o] Error 1
(This is based on some emails I exchanged with Axel and Wim, awaiting registration approval)
So - PyROOT seems to have the same problems as before after clean rebuilds of a brand new svn download and a clean Python 2.5.1 build (marred by one small bug that was easily fixed)
Python was built with
./configure --enable-framework
make
sudo make frameworkinstall
and ROOT with
svn co https://root.cern.ch/svn/root/trunk root; cd root
./configure macosx --enable-python --prefix=/usr/local/root
make
make cintdlls (seems unnecessary, now, but it was in the instructions)
sudo make install
Here’s the result:
[code]Python 2.5.1 (r251:54863, Nov 22 2007, 01:55:48)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.
from ROOT import *
Fatal Python error: Interpreter not initialized (version mismatch?)
Abort trap[/code]
Hi,
there seems to bee something fishy after all.
Building root works fine. Importing also works but when I try to use it it crashes.
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.
>>> import ROOT
>>>
>>> c = ROOT.TCanvas()
TCanvas::ResizePad:0: RuntimeWarning: c1 width changed from 0 to 10
TCanvas::ResizePad:0: RuntimeWarning: c1 height changed from 0 to 10
>>> g = ROOT.TGraph(2)
>>> g.SetPoint(0, 0, 0)
>>> g.SetPoint(1, 1, 1)
>>>
>>> g.Draw('AL')
*** Break *** bus error
/Users/hellesen/18226: No such file or directory.
Attaching to process 18226.
Reading symbols for shared libraries . done
Reading symbols for shared libraries ........................... done
0x93c44845 in wait4 ()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/Users/hellesen/lib/root/ROOT.py", line 254, in _displayhook
_root.gInterpreter.EndOfLineAction()
SystemError: problem in C++; program state has been reset
>>>
the end-of-display action will update the canvas, and doesn’t do much else. With trunk on my MacOS 10.3, I don’t see the RuntimeWarning nor the crash. Are you running under an X-windowing system? Does the canvas display to begin with?
Yes, its under X-Windows. Is there an alternative for OSX?
The canvas dont display to begin with as it normally does.
Could it be an X11 problem?
/Carl
I now understand what is happening on Leopard. On Leopard Apple ships all libraries as universal binaries with 4 architectures (ppc, ppc64, i386 and x86_64). This is nice, one library can be used on all platforms and be linked with any client program independent of the architecture for which the user compiled it. So on x86_64 ROOT is compiled by default as x86_64 and when linked against, e.g. libX11 it gets the x86_64 version of libX11. However, most user programs, like /bin/ls, and also /usr/bin/python, are shipped as universal but only with two architectures (ppc and i386). For /bin/ls this is fine, no need to have a 64 bit version, but for python this is not fine as python typically loads external libs and the libs may be only in x86_64 format, like libPyROOT. Hence this “architecture mismatch error”. I just tried on Leopard i386 where ROOT is compiled as i386 and here the python roottests succeed without problem. Also compiling on MacPro using as configuration target “macosx” instead of the auto detected “macosx64”, i.e. just building a 32 bit version of ROOT, PyROOT also works fine.
So there is nothing wrong with PyROOT, but with the fact that python does not exist for x86_64. There is no solution for the time being, until Apple ships python with x86_64 (the same is the case with Ruby and perl btw).
It still does not work. I compiled root with the architecture "macosx"on a fresh installation of OS X 10.5 (no upgrade from 10.4) using gcc 4.0.1.
It does not seem to be a PyROOT problem either. When I run the $ROOTSYS/tutorials/hsimple.C test as suggested I get the following output:
ROOT 5.17/09 (trunk@21358, De 20 2007, 08:22:00 on macosx)
CINT/ROOT C/C++ Interpreter version 5.16.27, Oct 25, 2007
Type ? for help. Commands must be C++ statements.
Enclose multiple statements between { }.
root [0]
Processing hsimple.C…
Warning in TCanvas::ResizePad: c1 width changed from 0 to 10
*** Break *** bus error
/Users/carlhellesen/root/tutorials/63522: No such file or directory.
Attaching to process 63522.
Reading symbols for shared libraries . done
Reading symbols for shared libraries … done
0x910de845 in wait4 ()
Root > Function hsimple() busy flag cleared
[quote=“rdm”]Also compiling on MacPro using as configuration target “macosx” instead of the auto detected “macosx64”, i.e. just building a 32 bit version of ROOT, PyROOT also works fine.
[/quote]
I wondered if building an universal Python 2.5 in MacPorts would get me off the hook, but the executable is i386, though the libs are universal:
I was wondering why ROOT macosx64 doesn’t compile code for both i386 and x86_64. I tried having “-arch i386 -arch x86_64” instead of “-m64” in Makefile.macosx64, which actually does not work.
I also wonder why building a MacPorts port with +universal doesn’t make the executable really universal…
