On Tue, Jan 12, 2010 at 12:16:31AM +0000, Duncan Coutts wrote:
> On Mon, 2010-01-11 at 20:19 +0000, Andrew Suffield wrote:
>
> > To reiterate, this is the exemplar use case for relocatable objects:
> >
> > Install ghc and some libraries to /usr/local/
> > Build some applications with ghc and install them into /home/asuffield/bin/
> > mv /usr/local/lib/*ghc* /srv/nfs-app-server/lib/
> > mv /home/asuffield /home/a/asuffield
> >
> > At this point, all previously compiled binaries should continue to
> > work without any intervention from the user. If they do not use rpath,
> > then they *do* work.
>
> You've really no right to expect this to work (and indeed it will not
> unless you use LD_LIBRARY_PATH). This is not a mode supported by any
> "./configure --prefix" style system.
On the contrary, this is supported by pretty much every shared
library, and is widely used on some large NFS-heavy sites. Very few
libraries have any business poking around in the filesystem (mostly
they just interact with fds supplied by the host application), hence
they are fully relocatable. It also appears to work with the GHC rts
when the libraries are not rpathed.
Again: rpath is the only thing that is stopping relocatable objects
from working.
> In any case, using rpath does not mean you cannot override it with
> LD_LIBRARY_PATH
You have this backwards. rpath overrides LD_LIBRARY_PATH. It overrides
everything, which is why it's so bad. The only thing you can do is use
--inhibit-rpath, but that requires you to maintain a full list of the
broken objects that have rpath entries, and use a wrapper script to
start every binary - in which case you might as well just forget the
whole thing and use LD_PRELOAD.
This is the search order on glibc systems (this is *not* portable
behaviour and there are no useful standards; every host operating
system must be handled separately):
0. If the object that caused this load has a DT_RUNPATH entry, go to 2
1. DT_RPATH of the object that caused this load
1r. If no DT_RPATH has yet been found, the parent object which caused
that one to be loaded; recurse until finding the first DT_RPATH in
the chain, or running out of objects.
2. DT_RPATH of the executable, regardless of whether we have already
checked another DT_RPATH or not.
3. LD_LIBRARY_PATH
4. DT_RUNPATH of the object that caused this load.
5. The contents of ld.so.cache, unless the object that caused this
load has the DF_1_NODEFLIB flag set.
6. The hardcoded search path in the dynamic loader. This is difficult
to predict but will usually contain /lib and /usr/lib and all their
subarch variations.
DT_RPATH is considered obsolete because this is just hideously
undesireable behaviour. DT_RUNPATH was supposed to replace it, but
since it only searches the object that caused the load, it does not
work with dlopen() (which has no cause). Users of dlopen() are
expected to use one of the other ways or do their own path searching.
The only things that really work the way people think they do are
LD_LIBRARY_PATH and ld.so.cache, and you really want to use
ld.so.cache if you can.
> It's only might of course since
> packages also often need to know their installation prefix to find
> libexec progs, or data files. Though again if packages are using Cabal's
> Paths module then even these locations can be overridden using env vars.
This, or a config file, is the normal behaviour for those few shared
libraries that need to locate global data in the filesystem, yes. When
new libraries are not relocatable, then they usually receive a patch
fairly promptly that adds an environment variable for this.
> And if you do move the libs too then you can
> use an LD_LIBRARY PATH, which you would have to do anyway if you're
> moving things out of /usr/local/lib.
Not if you're moving them to another location in the system search
path. Which you normally would be, in all the cases where you need to
relocate libraries.
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
