archives seem to indicate this has always been an issue, and while it's been
getting better over time, it hasnt really been considered "fully fixed".
what i'm looking at here is:
src/one/libone.la:
SOURCES = some files
src/two/libtwo.la:
SOURCES = some files
LDFLAGS = ../one/libone.la
when doing `make install DESTDIR=/some/place`, the relinking is fine for
libone.la. but when relinking libtwo.la, -L$libdir is incorrectly added to
the linking step. an -L flag pointing to the $DESTDIR/$libdir is added
before this and that's great ... it means libtwo.la is relinked against the
new/current version of libone.la and not some random old version in $libdir.
the problem with -L$libdir being added *at all* is cross-compiling. this
path can easily be a host libpath which means it gets searched before the
normal cross-compiler library paths.for example, if libtwo.la needs -lpthread, the -L$libdir path will cause the cross-linker to search $libdir for libpthread before falling back to the normal internal toolchain paths. sometimes the linker is lenient and just warns that the libpthread in $libdir is incompatible and so ignores it, but sometimes it's anal and will barf upon finding an incompatible library. glancing at CVS head, the situation seems to be unchanged. the code in question is in libltdl/config/ltmain.m4sh around line 4800 (the comment is "We cannot seem to hardcode it, guess we'll fake it"). -L$libdir is explicitly added to $add_dir without any checks. when installing into DESTDIR, i dont think this is desirable at all. -mike
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
