Re: rpath confusion on mac os x 10.6

From: Fons Rademakers <Fons.Rademakers_at_cern.ch>
Date: Fri, 29 Jan 2010 18:02:06 +0100

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
• if the application is not build with this option the dynamic link editor dyld must be told where to look for these libraries, it uses DYLD_LIBRARY_PATH (see "man dyld") and DYLD_FALLBACK_LIBRARY_PATH
• 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").

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

Received on Fri Jan 29 2010 - 18:02:11 CET