rpath for shared libraries
asuffield at suffields.me.uk
Mon Jan 11 15:19:48 EST 2010
On Mon, Jan 11, 2010 at 04:32:02PM +0000, Duncan Coutts wrote:
> There are advantages to not doing so. In particular multiple instances
> of the same version of a package, or multiple instances of the same ghc
> version can co-exist happily if they're isolated.
Why is this useful? I can't imagine a reason for wanting several
copies of exactly the same ghc around, that would not be better served
by changing the version on one of them at build time.
In any event, you could always install them into arbitrary private
locations. I don't think there is a use case for multiple instances of
exactly the same version installed into the global search paths for
applications to use.
> It lets you install
> ghc or a package into any test prefix and have things work.
Not relevant since those would just be the degenerate case of an
installation into some arbitrary private location, which would either
be added to the search path manually, or rpathed.
> It also lets
> us make a completely relocatable ghc installation.
No... it's the only thing that requires you to use rpath, which is
precisely the bit that makes the installation non-relocatable. Placing
the .so files directly in /usr/lib or some other directory in the
search path would be how you make a completely relocatable ghc
> In the absence of a
> proper package manager it's also an advantage in identifying which files
> need to be deleted to uninstall.
Given the number of other files that are spread around the filesystem,
I find it hard to believe this is a real goal.
> > /usr/lib/ghc-6.12.1/libHSrts.a
> > /usr/lib/ghc-6.12.1/base-126.96.36.199/...
> > /usr/lib/ghc-6.12.1/base-188.8.131.52/...
> > /usr/lib/ghc-6.12.2/libHSrts.a
> > /usr/lib/ghc-6.12.2/base-184.108.40.206/...
> > /usr/lib/ghc-6.12.2/base-220.127.116.11/...
> So why have we been using isolated locations for the static libs all
> this time? There must be some advantage.
Since static libraries are not required at runtime, it makes no
difference where you put them - no advantage, one location is as good
as any other.
> > I can't think of any use cases where this would break stuff, and
> > obviously it doesn't need rpath.
> > Are there any other reasons for scattering the .so files?
> I was thinking that installing into /usr/lib counts as scattering .so
> files. :-) If we're talking about "neatness" then having most package
> files under a couple dirs named after the package seems preferable (and
> is still FSH compliant).
Arbitrary definitions of 'neatness' are not a concern here, no. Only
> > > It's also the only option for per-user
> > > installations.
> > Not necessarily, I have $HOME/lib in my LD_LIBRARY_PATH. rpath is a
> > reasonable default here, though.
> Right. We cannot expect random users to set up an LD_LIBRARY_PATH. It's
> bad enough with the problems with the $PATH for programs cabal installs.
> Also, if we're ranking "badness" then surely LD_LIBRARY_PATH ranks as
> more of a hack last resort than does rpath.
No, integrating your private builds into the system search path is
preferable because it makes them relocatable, and using
LD_LIBRARY_PATH is the way you're supposed to do that. This is
mandatory for those of us who have home directories that exist in more
than one fixed location (typically, because they're a network mount on
heterogenous systems). rpath will not work here.
> > > ELF supports isolated installations perfectly well using
> > > rpath (and indeed relocatable libs using $ORIGIN). There's nothing icky
> > > about using rpath.
> > $ORIGIN is one of the several often-suggested attempts at solving the
> > problems with rpath that doesn't help, and makes the problem worse
> > because then your binaries aren't relocatable either (which makes
> > sysadmins cry).
> Huh? The program and the libs can use $ORIGIN.
> $prefix/bin/foo has -rpath '$ORIGIN/../lib' to find libfoo
> $prefix/lib/libfoo.so has -rpath '$ORIGIN' to find libbar
This works only if the libraries and binaries are installed into a
nextstep-style application bundle (for use as private libraries). It
is useless if, for example, you had a system with a global directory
where shared libraries are installed (say, /usr/lib) and want to build
a binary in a private location that is not fixed relative to that
directory (say, $HOME/bin). Such systems would appear to be common,
since that's all the unix-like systems.
> Of course you cannot
> relocate individual bits, but you don't want to do that.
I want to do that. That's the common case. Application bundles with
private libraries are really really rare (macosx is about the only
place you'll find them nowadays, and even there they've mostly
switched to using shared libraries).
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.
(There are many degenerate forms of this case which are arguably more
important - such as vendor upgrade paths - this one is picked for
clarity and to exercise all aspects of the problem)
More information about the Cvs-ghc