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
: LD_LIBRARY_PATH.

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 <tv@wasabisystems.com>  *  Wasabi & NetBSD:  Run with it.
-- CDs, Integration, Embedding, Support -- http://www.wasabisystems.com/