Re: Relinking to wrong version

[Dustin J. Mitchell]

On 10/11/07, Dustin J. Mitchell <address@hidden> wrote:
> It turns out that this cruft is coming from libcurl's configuration tool:
>   address@hidden /A/b $ curl-config --libs
>   -L/usr/lib64 -lcurl -L/usr/lib -lssl -lcrypto -ldl -lz
> So I'll trek on over there to see what that's about.

Turns out that the curl folks fixed this, more or less, in 7.16 --
they filter out /usr/lib, but not /usr/lib64, which appears on my
system.  There were a few other places that -L/usr/lib{,64} were
sneaking in, too, but once I removed those, the installs were fine.

AIUI, libtool is deciding to let the linker find libamanda, even
though libtool knows exactly where it is, and because of the spurious
-L/usr/lib (or, more generally, -L/path/to/the/wrong/libamanda) in
LDFLAGS, the linker is finding the wrong libamanda.  Because that
wrong libamanda.so has a version-specific soname, the linker then
embeds an incorrect library name (libamanda-2.6.2.so vs.
libamanda-2.6.3.so) into libDevice.so, so that even if the search
paths are correct at runtime, ld.so won't find the right libamanda.

Why is libtool letting the linker look for the library in the
mode=relink invocation, when it used an explicit path to the .so in
the mode=link invocation?

I'm *almost* to the point of understanding this.  Thanks for your patience.

Dustin

-- 
Storage Software Engineer
http://www.zmanda.com