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
