Re: Relative paths in *_LDADD vs absolute paths in .la dependencies

[Ralf Wildenhues]

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