Re: rpath confusion on mac os x 10.6

On 30/01/10 17:53, Tim Head wrote:
> Hello Fons,
>
> On 29 January 2010 11:02, Fons Rademakers<Fons.Rademakers_at_cern.ch> wrote:
>> Hi Tim,
>>
>> there a number of issues here:
>>
>> - we build the ROOT libs on Mac with @rpath so applications that
>> use in the link statement the -rpath option can bake in at which
>> location the ROOT libraries can be found. There is then no need to set
>> DYLD_LIBRARY_PATH before running these applications. In the ROOT
>> distribution all the root/bin binaries, like root.exe are built
>> with this option
>
> Does this baking in of the path to the libraries only happen when
> building executables? I was expecting it also to work for shared
> libraries. So that libPyROOT.so would know where libCore.so is located
> because it was "baked in" and so didn't set any of LD_PATH or
> DYLD_PATH.
>

Only executables.

> If I compile things by hand, and configure with --disable-rpath why is
> it still enabled? I mean, why provide the option if it doesn't seem to
> do anything?
>

is there mainly for Linux.

>>
>> - if an application loads at run-time via dlopen() a library then
>> dlopen() will look for the library first in LD_LIBRARY_PATH
>> then in DYLD_LIBRARY_PATH followed by DYLD_FALLBACK_LIBRARY_PATH
>> (see "man dlopen").
>
> From this I take it that rpath doesn't make my life simpler if I load
> libaries via dlopen() :(
>

No.

Cheers, Fons.

> I'll read up on rpath, there seems to be plenty of documentation out there :))
>
> Thank you,
> Tim
>
>>
>> So, to summarize:
>>
>> - no need to use the --disable-rpath option as it is used by the ROOT
>> binaries
>> - always set DYLD_LIBRARY_PATH to include $ROOTSYS/lib
>> - no need to set LD_LIBRARY_PATH as DYLD_LIBRARY_PATH is a fallback
>> for dlopen()
>> - the python executable is not linked with -rpath pointing to the ROOT
>> library directory hence it needs to get the location info from
>> DYLD_LIBRARY_PATH
>>
>> Hope this help.
>>
>> Cheers, Fons.
>>
>>
>> On 29/01/10 2:50, Tim Head wrote:
>>>
>>> Hello,
>>>
>>> I am trying to compile ROOT 5.26 on a mac running OS X 10.6.
>>>
>>> The compile went fine, but when I tried to import ROOT in python I got
>>> a strange error message:
>>>
>>> ImportError: dlopen(/Users/thead/homebrew/lib/libPyROOT.so, 2):
>>> Library not loaded: @rpath/libCore.so
>>> Referenced from: /Users/thead/homebrew/lib/libPyROOT.so
>>> Reason: image not found
>>>
>>> As the docs suggest that RPATH might be confusing, and I have no
>>> experience with it I thought the first thign to do is to disable it
>>> and see what happens. So I started from scratch, configuring with:
>>>
>>> $ ./configure macosx64 --disable-afs --disable-alien --disable-astiff
>>> --disable-bonjour --disable-castor --disable-chirp --disable-clarens
>>> --disable-dcache --enable-fftw3
>>> --with-fftw3-incdir=/Users/thead/homebrew/include/
>>> --with-fftw3-libdir=/Users/thead/homebrew/lib/ --disable-gviz
>>> --disable-gdml --disable-gfal --disable-g4root --disable-globus
>>> --disable-glite --enable-gsl-shared
>>> --with-gsl-incdir=/Users/thead/homebrew/include/
>>> --with-gsl-libdir=/Users/thead/homebrew/lib/ --disable-hdfs
>>> --disable-ldap --enable-mathmore --enable-minuit2 --disable-monalisa
>>> --disable-mysql --disable-odbc --disable-opengl --disable-oracle
>>> --disable-peac --disable-pgsql --disable-pythia6 --disable-pythia8
>>> --enable-python --disable-qt --disable-qtgsi --enable-reflex
>>> --disable-rfio --enable-roofit --disable-ruby --disable-sapdb
>>> --enable-shared --disable-srp --enable-ssl --disable-table
>>> --enable-unuran --disable-winrtdebug --disable-xrootd --enable-xft
>>> --disable-rpath
>>>
>>> However when I look at the output of the configure script:
>>>
>>> Enabled support for asimage, builtin_afterimage, builtin_ftgl,
>>> builtin_freetype, builtin_pcre, builtin_zlib, cint5, cintex, editline,
>>> exceptions, genvector, gsl_shared, mathmore, memstat, minuit2, python,
>>> reflex, roofit, rpath, shared, ssl, tmva, unuran, xft, xml.
>>>
>>> What am I missing?
>>>
>>> On the topic of RPATH, I thought the whole point of it was to have the
>>> path compiled in at compile time, so why do we need the env variable
>>> DYLD_LIBRARY_PATH to point anywhere? Most things google finds on this
>>> topic seem to be CUDA and Mac OS related, both topics I know very
>>> little about. So if someone could shed some light I would be very
>>> thankful.
>>>
>>> Tim
>>>
>>
>> --
>> Org: CERN, European Laboratory for Particle Physics.
>> Mail: 1211 Geneve 23, Switzerland
>> E-Mail: Fons.Rademakers_at_cern.ch Phone: +41 22 7679248
>> WWW: http://fons.rademakers.org Fax: +41 22 7669640
>>
>
>
>

-- 
Org:    CERN, European Laboratory for Particle Physics.
Mail:   1211 Geneve 23, Switzerland
E-Mail: Fons.Rademakers_at_cern.ch              Phone: +41 22 7679248
WWW:    http://fons.rademakers.org           Fax:   +41 22 7669640