libtool 1.5.x problems with multiple libtool libraries on search path

[James Henstridge]

Under some circumstances, libtool-1.5.x will prepend directories to the 
libtool search path, which can cause build problems.  Attached is a 
shell script that demonstrates this.

I have been able to reproduce this problem with the libtool-1.5.6 
package in Debian and libtool-1.5.10.  The problem doesn't seem to occur 
in libtool 1.9f.

The shell script creates a libbar.la/so in a B/ subdirectory, and two 
libfoo.la/so's in subdirectories A/ and B/.  The A/libfoo.la represents 
a new version of the library, and B/libfoo.la represents an old 
version.  If I try to link a program that requires libbar and the new 
version of libfoo with the following command:
   libtool --mode=link gcc -o main main.c -lbar -L$PWD/A -L$PWD/B -lfoo

Libtool picks up the copy of libfoo in the B/ subdirectory even though 
A/ comes first in the path, which causes a build failure due to missing 
symbols.

This problem also occurs if /usr/lib is used instead of B/.  In this 
case, the "-L$PWD/B" argument can be left off since it is in the default 
search path.  So the following command results in "main" being linked 
against /usr/lib/libfoo.la:
   libtool --mode=link gcc -o main main.c -lbar -L$PWD/A -lfoo

This is a problem when trying to build a set of packages into a 
non-standard prefix, since libtool can end up favouring libraries 
installed by the distribution instead of the ones in the build prefix.

If there is going to be another 1.5.x release, it would be nice if this 
problem could be fixed.  If this problem wasn't fixed intentionally in 
the 1.9 series it would be nice to have a test case (maybe my example 
script could be adapted to do this).

James.

build.sh
Description: Bourne shell script