Brief summary from the rpath discussion between Andrew and myself: One reason people find rpath annoying is that it overrides the LD_LIBRARY_PATH. This is the historical behaviour of the ELF DT_RPATH entry. There is a newer ELF DT_RUNPATH entry which fixes this behaviour, ie lets LD_LIBRARY_PATH override the DT_RUNPATH.
Whether an ELF lib or exe uses DT_RPATH or DT_RUNPATH is determined by the static linker, ld: ld -rpath --enable-new-dtags uses DT_RUNPATH ld -rpath --disable-new-dtags uses DT_RPATH Some Linux systems have configured binutils such that ld uses --enable-new-dtags by default. To use DT_RUNPATH reliably between Linux systems we will need to pass --enable-new-dtags to ld explicitly. We do definitely want the newer DT_RUNPATH behaviour. It's not just so that end users can relocate libs if they want to, we also want it for using libraries inplace in a build tree. For example in Cabal we want to do something like: $buildroot/dist/inplace/lib/libHSfoo.so $buildroot/dist/inplace/bin/foo We want the -rpath of foo and libHSfoo.so to be set for the final $prefix. We also want to run this inplace. For running inplace we can use a wrapper script that sets LD_LIBRARY_PATH and also the env var to tell the program to find its data files inplace in the build tree (the Cabal Paths_pkgname module has env vars for this purpose). This would also be relevant for the ghc build process. Currently for ghc we do not use rpath at all for the .so files for the core packages. I did it that way initially just to get it to work. Ideally we should move to setting the rpath for the final $prefix (which should actually be prefix independent using rpath $ORIGIN) and then use LD_LIBRARY_PATH to override things to use inplace in the build tree. Duncan _______________________________________________ Cvs-ghc mailing list Cvs-ghc@haskell.org http://www.haskell.org/mailman/listinfo/cvs-ghc
