On Mon, Apr 03, 2000 at 10:33:00PM -0700, NJ Verenini wrote:
> I looked at some of the software with the problem (how it built
> executables), and they all seem to do something like this:
> 
> gcc .libs/libfoo.so -o foo foo.c
> instead of something like
> gcc -o foo foo.c -L./libs -lfoo
> 
> Maybe that is part of the problem...
	Well, looking at the ldd output, it seems that linking the libs in
using the first method gets the path of the lib included with the name.
".libs/libfoo.so" instead of "libfoo.so".  What should happen is that
when the program gets linked it should figure out what the base name of
the lib is (w/o the path) and the path to it should go in a -Wl,-rpath
argument.
	With the number of problems that I've seen recently because of
missing -rpath stuff I'm inclined to suggest that a worthy improvement 
for the compile-time linker would be to automatically add the correct
path when given a relative path to a library or a -L... argument.
Especially since so many things don't know about -rpath.
i.e. gcc -o foo foo.c -L./.libs -lfoo should do what
     gcc -o foo foo.c -L./.libs -lfoo -Wl,-rpath,./.libs does now.
(currently, without the -rpath foo won't work correctly)

	There are other problems with the dynamic linker (like even
if it finds a library once it can lose it later: try adding 
"-L.libs -lfoo" to the first gcc line above and run "ldd ./foo")
but I don't think this particular problem is its fault.  It's the
compile-time linker including a path in a library name instead of
setting rpath.

eric