[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Relinking to wrong version

From: Dustin J. Mitchell
Subject: Re: Relinking to wrong version
Date: Fri, 12 Oct 2007 00:39:04 -0500

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 has a version-specific soname, the linker then
embeds an incorrect library name ( vs. into, so that even if the search
paths are correct at runtime, 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.


Storage Software Engineer

reply via email to

[Prev in Thread] Current Thread [Next in Thread]