Hi Charles

On 18 January 2011 02:38, Charles Wilson <libt...@cwilson.fastmail.fm> wrote:
> Right, but if you remove the $DESTDIR/$libdir from the relink command,
> then you'd break these native builds (because, e.g. /usr/lib is still in
> the compiler's default search path).
>
> For instance, suppose you're building gettext: it installs several so's
> (with interesting dependencies between them) AND a bunch of executables
> that depend on THOSE so's.  If you use $DESTDIR, and need to relink, but
> don't include $DESTDIR/$libdir in the -L spec, then you'd relink the
> executables (and so's with internal dependencies) against the versions
> installed by gettext-$OLDVER in /usr/lib.

I'm not trying to remove the $DESTDIR/$libdir reference; I'm trying to
remove the OS's /$libdir reference. Compare these relink commands,
adapted from previous email:

Current behaviour:
gcc *.o -L$DESTDIR/$libdir -L/$libdir -lgettextlib . . . -o
.libs/libgettextsrc-0.18.so

With my change:
gcc *.o -L$DESTDIR/$libdir -lgettextlib . . . -o .libs/libgettextsrc-0.18.so

The current behaviour already means it would find the newer gettextlib
dependency (because it gets installed in $DESTDIR/$libdir before
gettextsrc does). If anything I think my change would make it less
likely to find the old version of gettextlib. Hope we are
understanding each other :)

> If the new apps depend on any added/new interfaces...boom.

It sounds like you're describing something like what's going on in
this report, thought I haven't quite figured out how it happens:

"Relink with a DESTDIR install mistakenly links against old installed
libraries rather than those in DESTDIR"
http://savannah.gnu.org/support/?107416

-Martin

Reply via email to