On Tue, 2010-01-12 at 16:52 +0000, Simon Marlow wrote: > On 12/01/10 10:52, Duncan Coutts wrote: > > > 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. > > Just to summarise my understanding. If we want a $prefix-independent > binary distribution that contains dynamically-linked executables and > libraries, then we can either > > - not use rpath for installed libs/executables, and install > the .so files in a system-standard location (or add a new > subdir of /usr/lib to the standard set at install time). > > - or use $ORIGIN rpaths
Right. Though it's slightly hard to call it prefix independent if you have to install the libs in /usr/lib. But yes, it's location independent if you adjust the ld.so system-wide search path or set LD_LIBRARY_PATH. > I've seen various pros/cons of these two go past, perhaps someone could > summarise? I'm not sure I can. Apparently I just don't get what other people think is wrong with rpath. Duncan _______________________________________________ Cvs-ghc mailing list [email protected] http://www.haskell.org/mailman/listinfo/cvs-ghc
