PyROOT issues on OS X 10.11 (El Capitan)

After compiling on OS X 10.11 (El Capitan), I ran into the follow issue. The compilation went fine and reported no issues. ROOT also seems to work, but loading PyROOT goes wrong with the following error:

[code]gbesjes:~ source bin/root-6.05.02/bin/thisroot.sh gbesjes:~ python
Python 2.7.10 (default, Aug 22 2015, 20:33:39)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import ROOT
Traceback (most recent call last):
File “”, line 1, in
File “/Users/gbesjes/bin/root-6.05.02/lib/ROOT.py”, line 24, in
import cppyy
File “/Users/gbesjes/bin/root-6.05.02/lib/cppyy.py”, line 60, in
import libPyROOT as _backend
ImportError: dlopen(/Users/gbesjes/bin/root-6.05.02/lib/libPyROOT.so, 2): Library not loaded: @rpath/libTree.so
Referenced from: /Users/gbesjes/bin/root-6.05.02/lib/libPyROOT.so
Reason: image not found[/code]

This doesn’t seem like a PyROOT issue to me, but rather an issue with the library paths - hence the posting in this subforum. Is there any idea what this issue could be? Has it been seen before?

The installation is a fresh 10.11 install, with cmake installed from homebrew and the Apple-delivered python version (as can be seen from its version number).

I am having this same issue.

I am so disappointed in myself, that after 10 years using ROOT, I still cannot install it in under 2 days of Googling and tweaking and pulling my hair out :frowning:

I cannot be sure, but I think it has to do with the 32 bit vs. 64 bit versions of root/python, but I really am not sure.

$> otool -L /Applications/root_v5.34.32/lib/libPyROOT.so
/Applications/root_v5.34.32/lib/libPyROOT.so:
@rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0)
/System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.6)
@rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0)
@rpath/libCint.so (compatibility version 0.0.0, current version 0.0.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

>$ file which root
/Applications/root_v5.34.32/bin/root: Mach-O 64-bit executable x86_64

>$ file which python
/usr/bin/python: Mach-O universal binary with 2 architectures
/usr/bin/python (for architecture i386): Mach-O executable i386
/usr/bin/python (for architecture x86_64): Mach-O 64-bit executable x86_64

Need to set “LD_LIBRARY_PATH” to “$ROOTSYS/lib:$LD_LIBRARY_PATH”.

-Dom

Hi Dom,

Thank you for the reply, I tried this but it does not seem to take care of it-

jwwetzel@Jamess-MacBook-Pro-4:/Applications/root_v5.34.32$ export LD_LIBRARY_PATH=$ROOTSYS/lib:$LD_LIBRARY_PATH

jwwetzel@Jamess-MacBook-Pro-4:/Applications/root_v5.34.32$ python
Python 2.7.10 (default, Aug 22 2015, 20:33:39)

[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import ROOT
Traceback (most recent call last):
File “”, line 1, in
File “/Applications/root_v5.34.32/lib/ROOT.py”, line 103, in
import libPyROOT as _root
ImportError: dlopen(/Applications/root_v5.34.32/lib/libPyROOT.so, 2): Library not loaded: @rpath/libRIO.so
Referenced from: /Applications/root_v5.34.32/lib/libPyROOT.so
Reason: image not found

What gives:ls -l $ROOTSYS/lib
And if ok, what gives:DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT" |& grep libCore
Aside, if really 32b v.s. 64b issue (doubt it; if issue, expect loading libPyROOT.so itself to fail, not dependencies), can run:arch -x86_64 python
-Dom

And FWIW, macports has what you want:root5 @5.34.32 science/root5
-Dom

Try running Cmake with -Drpath=on. I guess there is a similar option also for configure. This works at least for me.

Is “–enable-rpath” for configure. Is on by default on Mac.

-Dom

Hi Dom,

Thank you again for helping me out here.

I recompiled everything, and tried to get things set right, but I am still getting the same error.

I compiled 6.05/02 using

./configure macosx64 --enable-python

But I have also tried 5.34 and the binaries. I am on OS X 10.11. ROOT itself works fine.

ls -l $ROOTSYS/lib

gives me:

total 175752....

and

DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT" | grep libCore

gives me:

jwwetzel@Jamess-MacBook-Pro-4:/Applications/root$ DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT" | grep libCore Traceback (most recent call last): File "<string>", line 1, in <module> File "/Applications/root/lib/ROOT.py", line 24, in <module> import cppyy File "/Applications/root/lib/cppyy.py", line 60, in <module> import libPyROOT as _backend ImportError: dlopen(/Applications/root/lib/libPyROOT.so, 2): Library not loaded: @rpath/libCore.so Referenced from: /Applications/root/lib/libPyROOT.so Reason: image not found

Edit:

I also get this result:

jwwetzel@Jamess-MacBook-Pro-4:/Applications/root_v5.34.32$ otool -L /Applications/root_v5.34.32/lib/libPyROOT.so /Applications/root_v5.34.32/lib/libPyROOT.so: @rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.6) @rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libCint.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

HOWEVER! If I run my python script THROUGH root, I have no problem:

[code]root [0] TPython::Prompt()

execfile(‘analyzeFiles.py’)[/code]

This is perfectly successful. So somehow my environment is not communicating properly, and I have no idea which part is broken.

Have a look at the output of

otool -l /Applications/root_v5.34.32/lib/libPyROOT.so

At some point (towards the end) it should contain a line cmd LC_RPATH and two lines below something like path /Applications/root_v5.34.32/lib. If it does not you could try to execute in bash:

for i in /Applications/root_v5.34.32/lib/lib*.so ; do
install_name_tool -add_rpath /Applications/root_v5.34.32/lib $i
done

But this is not tried out, for me everything worked after I used cmake with the rpath option.

I’m not sure why we’re suddenly talking about v5.34.32. The version I’m trying to compile is the latest ROOT6 version, which gives the same error.

gbesjes@imac-besjes:~ $ source bin/root-6.02.12/bin/thisroot.sh gbesjes@imac-besjes:~ $ echo $LD_LIBRARY_PATH /Users/gbesjes/bin/root-6.02.12/lib

The paths are OK:

/Users/gbesjes/bin/root-6.02.12/lib/libPyROOT.so: @rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10) @rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

Setting $DYLD_LIBRARY_PATH to $LD_LIBRARY_PATH does not solve the issue.

A different machine with a ROOT6 installation on OS X 10.10 has rather similar output:

gbesjes@supermac:~ $ otool -L $ROOTSYS/lib/libPyROOT.so /cvmfs/atlas.cern.ch/repo/ATLASLocalRootBase/x86_64-MacOS/root/6.02.12-x86_64-mac1010-clang61-opt/lib/libPyROOT.so: @rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.6) @rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1213.0.0)

This seems to me the same as above. What I ran is the following:

This solves the issue. The output of otool is now:

gbesjes@imac-besjes:~ $ otool -L $ROOTSYS/lib/libPyROOT.so /Users/gbesjes/bin/root-6.02.12-rpath-hack/lib/libPyROOT.so: @rpath/libPyROOT.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libTree.so (compatibility version 0.0.0, current version 0.0.0) /System/Library/Frameworks/Python.framework/Versions/2.7/Python (compatibility version 2.7.0, current version 2.7.10) @rpath/libRIO.so (compatibility version 0.0.0, current version 0.0.0) @rpath/libCore.so (compatibility version 0.0.0, current version 0.0.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1225.1.1)

Which, as you can see, has not changed. My original compilation command was

cmake -DCMAKE_INSTALL_PREFIX=$HOME/bin/root-6.02.12 -DCMAKE_BUILD_TYPE=Release -Dall=ON ../root-6.02.12 make -j6 make install

Presumably, something in the cmake (or autoconf, judging from the other issues reported) goes wrong on 10.11 w.r.t. 10.10. It would be great if it could be fixed - I don’t think setting rpath by hand makes the binary very portable!

This rpath hack does seem to break dynamic includes.

I have a library libSusyFitter.so that needs to be found in /Users/gbesjes/work/HistFitter/lib, which is nicely in $LD_LIBRARY_PATH:

gbesjes@imac-besjes:~$ echo $LD_LIBRARY_PATH /Users/gbesjes/work/ZeroLeptonFitter-Run2/lib:/Users/gbesjes/work/HistFitter/lib:/Users/gbesjes/bin/root-6.02.12-rpath-hack/lib

However, attempting to load it through ROOT.gSystem.Load(‘libSusyFitter.so’) goes wrong:

I’m surprised at this search path: it completely ignores LD_LIBRARY_PATH and also DYLD_LIBRARY_PATH.

DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT" | grep libCoreshould give more information than posted.

Installed El Capitan, rebuild ROOT master. Fails at:cp: etc/cling/lib/clang/3.7.0/include/wchar.h: Permission denied make: *** [etc/cling/lib/clang/3.7.0/include/wchar.h] Error 1Scrubbed that, build completes, “import ROOT” works fine. Have macports python, though.

Cleaned PyROOT, removed port, rebuild with system python … Fails like yours.

@suhl: which python do you use?

-Dom

[quote=“Dominique”]DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT" | grep libCoreshould give more information than posted.
[/quote]

I’m afraid it doesn’t:

gbesjes@imac-besjes:~ $ DYLD_PRINT_LIBRARIES_POST_LAUNCH=1 python -c "import ROOT; ROOT.gSystem.Load('libSusyFitter.so')" Error in <TMacOSXSystem::FindDynamicLibrary>: libSusyFitter.so does not exist in .:/Users/gbesjes/bin/root-6.02.12-rpath-hack/lib::/usr/local/lib:/usr/X11R6/lib:/usr/lib:/lib:/lib/x86_64-linux-gnu:/usr/local/lib64:/usr/lib64:/lib64:

It is, by the way, an issue that does not arise in the interpreter:

[code]root [0] gSystem->Load(“libSusyFitter.so”)

RooFit v3.60 – Developed by Wouter Verkerke and David Kirkby
Copyright © 2000-2013 NIKHEF, University of California & Stanford University
All rights reserved, please read http://roofit.sourceforge.net/license.txt

(int) 0[/code]

I use the one by Apple (version 2.7.10).

To me this does not really seem to be an issue of ROOT (at least not directly), but seems to be related to the new “System Integrity Protection” (which unfortunately I did not really find a lot of information about). If you start python you will notice that the DYLD_LIBRARY_PATH is unset (i.e. if you call os.getenv(“DYLD_LIBRARY_PATH”) the result is empty). And I guess similar DYLD_* environment variables are also not passed on. So basically you have to take care that libraries you want to load from python know about all paths to search for other libraries your initial library is linked against, either by setting proper rpaths in your libraries, or by using the full paths in the library name (the result of otool -D) of the libraries linked against.

Indeed; and with the MacPorts Python the env is non-empty.

-Dom

With the homebrew Python I still need the following:

#!/usr/bin/env python import os import ROOT ROOT.gSystem.Load('{0}/lib/libSusyFitter.so'.format(os.getenv('HISTFITTER'))) print("test OK")

Even when $HISTFITTER/lib is in my LD_LIBRARY_PATH. Do you not see any such behaviour with the MacPorts python? That would be a surprising difference.

I just committed some changes to v5-34-00-patches and v6-02-00-patches that should fix this problem with the treatment of RPATH that has caused problems with OS X 10.11 when building with CMake. The master and v6-04-00-patches didn’t suffer from this problem.
The default behavior is that RPATH is used for the build tree and is removed during the installation unless the option ‘rpath’ is set to true (-Drpath=ON), which will use RPATH pointing to the installation directory. A new patch version 5.34/34 is going to be release this afternoon.

Still leaves general problem. Here for ctypes:[code]% /usr/bin/python
importPython 2.7.10 (default, Aug 22 2015, 20:33:39)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.1)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import ctypes
ctypes.CDLL(“libtruc.so”)
Traceback (most recent call last):
File “”, line 1, in
File “/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ctypes/init.py”, line 365, in init
self._handle = _dlopen(self._name, mode)
OSError: dlopen(libtruc.so, 6): image not found
ctypes.CDLL(“lib/libtruc.so”)
<CDLL ‘lib/libtruc.so’, handle 7f8ada62c2b0 at 10767fd50>
[/code]
versus:

[code]% /opt/local/bin/python2.7
Python 2.7.10 (default, Oct 2 2015, 00:54:24)
[GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import ctypes
ctypes.CDLL(“libtruc.so”)
<CDLL ‘libtruc.so’, handle 7fa9fa70eb30 at 10cbd6bd0>
[/code]
-Dom