Hello Olly, Apologies for the long delay.
* Olly Betts wrote on Mon, Jul 10, 2006 at 07:39:10PM CEST: > > /bin/sh ../libtool --tag=CXX --mode=link g++ -o quartzcheck \ > quartzcheck-quartzcheck.o ../testsuite/libbtreecheck.la ../libxapian.la > > causes libtool to execute (my wrapping): > > g++ -o .libs/quartzcheck quartzcheck-quartzcheck.o \ > ../testsuite/.libs/libbtreecheck.a \ > /s2/olly/svn/xapian/xapian-core/.libs/libxapian.so ../.libs/libxapian.so \ > -Wl,--rpath -Wl,/u1/olly/install/lib > > The full path to libxapian.so comes from libbtreecheck.la's > dependencies, while the relative path (which leads to the same files) > comes from the link line. > > I think this is mostly a cosmetic problem, except that it probably > causes the linker more work unless it realises the two libxapian.so's > are actually the same. Yes. Fixing this in Libtool is a TODO item. AFAIK it's harmless though (it does generate a warning with the Solaris linker). > Is there a way to avoid this happening - e.g. are paths to .la files > specified in LDADD meant to be absolute rather than relative? No, paths to uninstalled libraries (i.e., within the same package) are meant to be passed relative. As a workaround you could pass libxapian prefixed with $(abs_top_builddir)/... in all cases, but IMHO it's not worth the trouble. > I'd rather not remove the explicit mention of libxapian.la from > quartzcheck_LDADD since it's really an implementation detail of > libbtreecheck.la that it depends on libxapian.la. Definitely. Hope that helps. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
