CompileMacro problems in pyroot+root6+OSX

I can’t use gSystem.CompileMacro() when I use all three of [ root6, OSX and PyROOT ].

I do not have problems with [root6, SLC, PyROOT] or [root5, OSX, PyROOT].

Details:

In the “lab”, on an SLC6 machine, I can use PyROOT to do this successfully:

##############################################
pcil–bash$ root-config --version
6.02/05
pcil–bash$ cat << EOF > moo.cxx
int moo() { return 7; }
EOF
pcil–bash$ python2.7
Python 2.7.4 (default, May 5 2013, 17:33:10)
[GCC 4.8.0] on linux2
Type “help”, “copyright”, “credits” or “license” for more information.

import ROOT
ROOT.gSystem.CompileMacro(“moo.cxx”)
Info in TUnixSystem::ACLiC: creating shared library /var/clus/usera/lester/LESTERHOME/proj/Athena/c++/XAODCode/trunk/moo_cxx.so
1
ROOT.moo()
7
#################################################

On my osx macbook (intel), where I have root6 (version 6.03/03) installed via macports, PyROOT does not succeed any more:

##########################################
lester@mac:~ root-config --version 6.03/03 lester@mac:~ cat << EOF > moo.cxx
int moo() { return 7; }
EOF
lester@mac:~ $ python2.7
Python 2.7.10 (default, May 25 2015, 13:06:17)
[GCC 4.2.1 Compatible Apple LLVM 6.0 (clang-600.0.56)] on darwin
Type “help”, “copyright”, “credits” or “license” for more information.

import ROOT
ROOT.gSystem.CompileMacro(“moo.cxx”)
Info in TMacOSXSystem::ACLiC: creating shared library /Users/lester/moo_cxx.so
ld: can’t link with bundle (MH_BUNDLE) only dylibs (MH_DYLIB) file ‘/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/lib-dynload/_locale.so’ for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Error in : Compilation failed!
0
###############################################

However on the same osx macbook I can succeed if I DON’T use PyRoot, instead using ROOT directly:

##############################################################
lester@mac:~ $ root

| Welcome to ROOT 6.03/03 root.cern.ch |
| (c) 1995-2014, The ROOT Team |
| Built for macosx64 |
| From tag , 27 January 2015 |

Try ‘.help’, ‘.demo’, ‘.license’, ‘.credits’, ‘.quit’/‘.q’
root [0] gSystem->CompileMacro(“moo.cxx”)
Info in TMacOSXSystem::ACLiC: creating shared library /Users/lester/moo_cxx.so
(int) 1
root [1] moo()
(int) 7
root [2]
###############################################################

Note, with root5, there are no problems on EITHER machine – so the problem seems to involve all three of osx, root6 and pyroot.

Ideas?

Christopher

P.S. On the mac

lester@mac:~ $ clang --version
Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
Target: x86_64-apple-darwin14.3.0
Thread model: posix

Update:

I tried upgrading to root 6.04/00 to see if that would help.

Things are even worse now. Whereas previously I could not compile moo.cxx with PyROOT but was still able to do it in root directly. Now I can’t even do it in root directly:

lester@mac:~ $ root-config --version
6.04/00
lester@mac:~ $
lester@mac:~ $ cat moo.cxx
int moo() { return 7; }
lester@mac:~ $ root

| Welcome to ROOT 6.04/00 root.cern.ch |
| © 1995-2014, The ROOT Team |
| Built for macosx64 |
| From tag , 2 June 2015 |

Try ‘.help’, ‘.demo’, ‘.license’, ‘.credits’, ‘.quit’/’.q’

root [0] gSystem->CompileMacro(“moo.cxx”)
Info in TMacOSXSystem::ACLiC: creating shared library /Users/lester/moo_cxx.so
In file included from input_line_14:1:
In file included from /opt/local/libexec/root6/include/root/TStreamerInfo.h:26:
In file included from /opt/local/libexec/root6/include/root/TVirtualStreamerInfo.h:25:
In file included from /opt/local/libexec/root6/include/root/TNamed.h:29:
In file included from /opt/local/libexec/root6/include/root/TString.h:41:
In file included from /opt/local/libexec/root6/include/root/RStringView.h:26:
/opt/local/libexec/root6/include/root/RWrap_libcpp_string_view.h:329:4: error: redefinition of ‘__find_first_of_ce’
__find_first_of_ce(_ForwardIterator1 __first1, _ForwardIterator1 __last1,
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/include/c++/v1/algorithm:1047:1: note:
previous definition is here
__find_first_of_ce(_ForwardIterator1 __first1, _ForwardIterator1 __last1,
^
In file included from input_line_14:1:
In file included from /opt/local/libexec/root6/include/root/TStreamerInfo.h:26:
In file included from /opt/local/libexec/root6/include/root/TVirtualStreamerInfo.h:25:
In file included from /opt/local/libexec/root6/include/root/TNamed.h:29:
In file included from /opt/local/libexec/root6/include/root/TString.h:41:
In file included from /opt/local/libexec/root6/include/root/RStringView.h:26:
/opt/local/libexec/root6/include/root/RWrap_libcpp_string_view.h:342:4: error: redefinition of ‘__str_find’
__str_find(const _CharT *__p, _SizeT __sz,
^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/…/include/c++/v1/string:998:1: note:
previous definition is here
__str_find(const _CharT *__p, _SizeT __sz,
^
In file included from input_line_14:1:
In file included from /opt/local/libexec/root6/include/root/TStreamerInfo.h:26:
In file included from /opt/local/libexec/root6/include/root/TVirtualStreamerInfo.h:25:
In file included from /opt/local/libexec/root6/include/root/TNamed.h:29:
In file included from /opt/local/libexec/root6/include/root/TString.h:41:

… and many hundred lines more …

Hi,

The cause is likely that you have only a partial or inconsistent macports environment.

Was that macports build done with GCC? Then do you have the appropriate GCC installed? Apparently python from macports doesn’t play nice with the linker either.

Bottom line: why don’t you get rid of all that, install a current Xcode and grab the ROOT binaries from the web page root.cern.ch/drupal/content/pro … ersion-604 ?

Cheers, Axel.

Thank you for this remarkably simple suggestion. As it happens, my Xcode was already the most up-to-date one available, so I could “sudo port uninstall root5 root6” and then grab the dmg from the link you suggested.

It does indeed work out-of-the-box.

I previously hadn’t had any problems with macports, and used it for many other things long before I considered using it to download root, and had previously used other versions of root from macports without problem. So I hadn’t expected/anticipated that the issue would be in the macports packaging, and assumed I was getting the same thing from them that I would from a direct download. But I see now that was not the case.

Thank you again,

Christopher

[quote=“Axel”]Hi,

The cause is likely that you have only a partial or inconsistent macports environment.

Was that macports build done with GCC? Then do you have the appropriate GCC installed? Apparently python from macports doesn’t play nice with the linker either.

Bottom line: why don’t you get rid of all that, install a current Xcode and grab the ROOT binaries from the web page root.cern.ch/drupal/content/pro … ersion-604 ?

Cheers, Axel.[/quote]