Subject: Re: "-Ldir -lname" vs. "dir/libname.so"
To: Nick Hudson <firstname.lastname@example.org>
From: Todd Vierling <email@example.com>
Date: 03/14/2002 10:52:11
On Thu, 14 Mar 2002, Nick Hudson wrote:
: > [ELF]
: > cd libfoo
: > cc -shared -o libfoo.so.0.0 -Wl,-soname,libfoo.so.0 ... \
: > -R/usr/pkg/some/lib -L/usr/pkg/some/lib -lsomelib
: > ln -s libfoo.so.0.0 libfoo.so.0
: > ln -s libfoo.so.0.0 libfoo.so
: > cd ../libbar
: > cc -shared -o libbar.so.0.0 -Wl,-soname,libbar.so.0 ... \
: > -R/usr/pkg/foo/lib -L../libfoo -lfoo \
: > -Wl,-rpath-link,/usr/pkg/some/lib
: Two things to note about this are
: - The -Wl,-rpath-link part is no longer needed. The 2.11.2 based ld and the
: patched 2.9.3 ld (in 1.5.3) automatically look for NEEDED libraries in the
: RPATH of the dependent library.
: - The uninstalled libbar won't contain the necessary RPATH to find the
: uninstalled libfoo.
You just contradicted yourself. If -Wl,-rpath-link is not needed as you
say, then the only place ld can find out libfoo's location is from the rpath
... which points at a directory where libfoo is not yet installed! (Yes,
I'm assuming that libbar is being linked with an rpath pointing at *only*
the install path of libfoo, as I illustrated in my examples.)
The -rpath-link is needed in order to resolve uninstalled dependencies, such
as the one on libfoo. This is the *correct* way to do a link of a shared
object with dependencies on ELF.
Relinking is working around the problem incorrectly, with the caveats I've
already mentioned: you can end up linking against the wrong library, or
worse, end up with the wrong or a missing rpath in the installed library.
: I believe that this is wrong as libtool supports the ability to use
: uninstalled libraries as part of a debug process. relinking is needed to
: generate the installed versions with the correct RPATH entries.
: I believe there is a much simpler way of supporting this. If libtool were to
: use install paths in uninstalled libraries and binaries then, using the
: normal wrapper scripts, it could simply override the RPATHs using
rpath entires pointing into the source tree are simply *wrong*. You can use
LD_LIBRARY_PATH (as you mention) if you need a temporary debug path to make
it work -- the libraries as linked, the first time around, should have the
correct rpaths for install time.
libtool did precisely this at one time. Did it change? Last time I
checked, libtool created shell wrapper scripts (outside the .libs directory,
with the same name as the binary in .libs) that sets LD_LIBRARY_PATH to
allow running the binaries in-tree.
: Obviously this assumes that all platforms have the equivalent of
: LD_LIBRARY_PATH which may not be true.
All ELF platforms do, and non-ELF platforms usually don't have rpath at all
(meaning that you'd need some similar mechanism anyway). As noted above,
libtool had this logic for ages....
-- Todd Vierling <firstname.lastname@example.org> * Wasabi & NetBSD: Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/