Re: Re: Recovering the underlying TObject from a PyObject

From: Tim Head <betatim_at_gmail.com>
Date: Wed, 25 Aug 2010 15:46:58 -0500


Hello Wim,

>> tree in python: <ROOT.TTree object at 0x104c42ef0>
>> pytree: <ROOT.TTree object at 0x104c42ef0>
>> ttree again: 0
>

Now I get:

tree in python: <ROOT.TTree object at 0x104de5290> pytree: <ROOT.TTree object at 0x104de5290> ttree again: 0x104de5290

Hurray!

What did I change? After reading around the internet I got the impression that people use libtool on MacOS to link shared libraries. I haven't educated myself enough to understand what exactly is better/more fancy about it but it might be because of the complicatedness added by Mach-O and multi platform stuff. Anywho, this is what I changed to make it work. At the top of the files I sent a while ago to reproduce the problem I added:

compilecmd = "g++ -c $Opt -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -D_REENTRANT -pthread $IncludePath $SourceFiles"
linkcmd = "libtool -dynamic -o $SharedLib -undefined dynamic_lookup $ObjectFiles"

R.gSystem.SetMakeSharedLib('cd $BuildDir ; %s ; MACOSX_DEPLOYMENT_TARGET=10.6 %\ s'%(compilecmd, linkcmd))

Maybe someone who has some more experience can comment on what the difference between the resulting MakeSharedLib() command and the default one I have which is:

cd $BuildDir ; g++ -c $Opt -m64 -pipe -W -Wall -Woverloaded-virtual -fsigned-char -fno-common -D_REENTRANT -pthread $IncludePath $SourceFiles ; MACOSX_DEPLOYMENT_TARGET=10.6 g++ $ObjectFiles -dynamiclib -single_module -undefined dynamic_lookup -O2 -m64 $DepLibs -o $SharedLib

Thanks,
Tim

-- 
http://tim.jottit.com/
Received on Wed Aug 25 2010 - 22:47:04 CEST

This archive was generated by hypermail 2.2.0 : Sun Aug 29 2010 - 17:50:01 CEST