On Tue, Apr 04, 2000 at 10:35:40AM -0500, John Darrow wrote:
> The linker is doing exactly what we tell it to, linking in an object
> '.libs/libfoo.so' into an executable.  It could be argued that the path
> should be stripped from the internal table if the object turns out to be
> a shared library (thus resulting in a runtime-type link).  But see below.
	It already ends up being a runtime-type link, just with an
unusual name.

> gcc -o foo foo.c -L./.libs -lfoo -Wl,-rpath,/usr/local/lib
> 
> On both a.out and elf, this will produce an executable which will just
> work, without the need of either ldconfig or LD_LIBRARY_PATH.
	uh, no.  This doesn't work.  Try it.  You're going to have to
set LD_LIBRARY_PATH in order for "./foo" to be able to find the
library.  

> The point is that locations like './.libs' are _temporary_ - they are
> used during the build process, and will probably no longer exist once the
> program is installed.  We don't want the runtime loader wasting time
> looking up directories which don't exist.  (It's for reasons like this
> that the -L does _not_ automatically stuff in a runtime path.)
	yes, those type of locations are temporary.  So the completely
correct solution would be to make whatever piece of software you're building
set LD_LIBRARY_PATH to the temporary directory.  But this means you're 
going to have to go changing the build process for everything that
excepects -L... to do the right thing.  
	Sure, it would be nice if every piece of software knew all the
quirks of linking against shared libs on NetBSD, but they don't.  It makes
a lot of sense to me to be compatible with what external software packages
expect.  It seems to me that the ideal behaviour would be to enable what
happens with ld on SunOS (according to the gnu ld man page, look under -rpath)
-L... args add to rpath unless rpath is explicitly set.

eric