Re: Relinking to wrong version

[Dustin J. Mitchell]

On 10/11/07, Ralf Wildenhues <address@hidden> wrote:
> 1) Because ../common-src/libamanda.la was an uninstalled library
> (it has "installed=no" inside), libtool expects that, upon installation
> of a library (libDevice.la), all its dependent uninstalled libraries
> (libamanda.la) have already been installed.  So it expects that
> /A/p/lib/libamanda.la does exist (and is the just-installed library).
> Is that the case?

Yes:
address@hidden /A/b/perl $ ls /A/p/lib/amanda/libamanda[-.]*
/A/p/lib/amanda/libamanda-2.6.3.so  /A/p/lib/amanda/libamanda.a
/A/p/lib/amanda/libamanda.la  /A/p/lib/amanda/libamanda.so

> 2) /A/p/lib/libamanda would be found by the relink command that libtool
> generates, except that your mode=link command happened to put -L/usr/lib
> early in the path.  Why is that, I can't see why that would be needed?
>
> Please try to execute the mode=link command that you posted, but remove
> the -L/usr/lib.  Then try the mode=install command.  Does the relink
> work right now?
>
> If yes, then it remains to find out where that originally came from.

Just removing -L/usr/lib from the mode=link command left -L/usr/lib
and -L/usr/lib64 in the libDevice.la file, and thus didn't help the
situation.  However, manually editing these options out of
libDevice.la caused the mode=install command to produce a correctly
installed executable.

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.

Also, your point #1 suggests that this won't be a problem for users
installing over an older version, because the new libamanda.{so,la}
will already be installed when the new libDevice.la gets relinked.  So
I'll happy hack around this in some way gets me back to coding.

Thanks for your spot-on analysis!

Dustin

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