On Tue, 2010-01-12 at 01:49 +0000, Andrew Suffield wrote:
> 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.
man ld.so says:
The shared libraries needed by the program are searched for in the
following order:
* (ELF only) Using the directories specified in the DT_RPATH
dynamic section attribute of the binary if present and
DT_RUNPATH attribute does not exist. Use of DT_RPATH is
deprecated.
* Using the environment variable LD_LIBRARY_PATH. Except if the
executable is a set-user-ID/set-group-ID binary, in which case
it is ignored.
* (ELF only) Using the directories specified in the DT_RUNPATH
dynamic section attribute of the binary if present.
Indeed you can test this and find that this is exactly how it behaves.
$ ./main
42
$ LD_LIBRARY_PATH=bar ./main
43
This is a main linking to libfoo.so via rpath but overridden to link to
a separate ./bar/libfoo.so that exports a different implementation of
extern int foo();
> 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.
Is your concern about old .so libs that have an DT_RPATH but no
DT_RUNPATH entry and thus invoke the old behaviour?
Duncan
_______________________________________________
Cvs-ghc mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/cvs-ghc
