[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Relinking to wrong version
From: |
Ralf Wildenhues |
Subject: |
Re: Relinking to wrong version |
Date: |
Fri, 12 Oct 2007 08:04:44 +0200 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
* Dustin J. Mitchell wrote on Fri, Oct 12, 2007 at 07:39:04AM CEST:
>
> 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?
Hmm, I would have to go and check whether there is something that
*requires* libtool to do so on GNU/Linux. It's the case on some other
systems that, with an explicit path to the .so on the command line, the
system linker puts that whole path in the DT_NEEDED entry, rather than
just the basename of it (IIRC OpenBSD was a candidate for this). Which
is undesirable for several reasons.
But on GNU/Linux this only happens if the dependent library wasn't given
a soname, which libtool takes care of to do for libraries it builds.
OTOH, I can think of a good reason libtool wouldn't want to operate any
differently: third-party users of said installed library expect to be
able to link against it using `-LLIBDIR -llib' (let's ignore run-time
issues for the moment). Thus we should be able to, too, as soon as this
library is installed. So at least it serves as a good kind of test
whether your installation works or not. If this fails due to other
versions of the library in previously-listed search directories, then
third-party users (who may also list those search directories early, due
to unrelated libraries) will have the same problems. Makes sense?
Cheers,
Ralf