Re: Debugging Libtool's Insistence on Sourcing a Library from /usr/lib Rather Than LDFLAGS

[Grant Erickson]

On 2/9/08 11:10 AM, Ralf Wildenhues wrote:
> * Grant Erickson wrote on Wed, Feb 06, 2008 at 07:04:36PM CET:
>> I am attempting to debug an issue involving libtool from the avahi-0.6.22
>> package sourcing the local (i686-unknown-linux-gnu) version of libexpat
>> (-lexpat) rather than the I one I direct it to find via LDFLAGS.
> [...]
>> If I pass Œ--debug¹ to libtool, it seems to find the correct
>> Œ/tmp/src/results/avahi/../expat/usr/lib/libexpat.la¹ file; however, it
>> latter seems to ignore that and pick-up Œ/usr/lib/libexpat.so¹ anyway:
> 
> Your report is almost complete, but it would help me to have the whole
> --debug output, not just parts of it.  You should pack it with bzip2 or
> gzip.
> 
> [...]
>>> + . 
>>> /tmp/src/results/avahi/../expat/usr/lib/libexpat.la
>>> ++ dlname=libexpat.so.1
>>> ++ library_names='libexpat.so.1.5.2 libexpat.so.1 libexpat.so'
>>> ++ old_library=libexpat.a
>>> ++ dependency_libs=
>>> ++ current=6
>>> ++ age=5
>>> ++ revision=2
>>> ++ installed=yes
>>> ++ shouldnotlink=no
>>> ++ dlopen=
>>> ++ dlpreopen=
>>> ++ libdir=/usr/lib
> 
> This looks fishy.  The library lives below
> /tmp/src/results/avahi/../expat/usr/lib
> but its libdir is /usr/lib.  That seems wrong.
> 
> Further, is that
>   /tmp/src/results/avahi/../expat/usr/lib/libexpat.la
> 
> path an installed location or an uninstalled one?
> Can you link against it using
>   ../relative/path/to/libexpat.la
> ?
> 
> Cheers,
> Ralf

Ralf,

Thanks for the prompt response. I have since figured out what seems to be
the root cause of the issue and a work around. Here's the response I posted
to the Avahi list:

> Anthony,
>
> Regrettably, the solution I suggested previously [changing prefix to
> $(resultdir)], while it successfully builds, introduces some undesirable
> runtime problems.
> 
> As I mentioned previously, if Avahi's libtool finds a '*.la' file for either
> the libdaemon or expat library, it uses the value of 'libdir=<dir>' it finds
> therein.
> 
> If '--prefix=/usr' for either libdaemon or expat, then this 'libdir' value
> is '/usr/lib'. Libtool then translates '-lexpat' (or '-ldaemon') on the link
> line to '/usr/lib/libexpat.so' (or '/usr/lib/libdaemon.so').
> 
> In a cross-compilation environment, this is likely to be neither the right
> architecture nor the right version of the library to link against. In short,
> [things fail] at build time.
> 
> As I suggested in the prior e-mail, we could also handle this by removing
> DESTDIR and setting the prefix to $(resultdir). This, indeed, fixes the
> build-time problem. However, it results in libtool adding $(resultdir)
> as the RPATH in the linked executable which is NOT what we want either.
> [Things fail] again, but this time at run time.
> 
> It turns out that by REMOVING the '*.la' file for both expat and libdaemon,
> we succeed at both build- and run-time by ensuring neither a misdirected link
> nor an incorrect RPATH.
> 
> So, once again, configure libdaemon and expat like:
> 
>     cd $(objdir) && \
>     $(srcdir)/configure \
>     CC=$(CC) AR=$(AR) RANLIB=$(RANLIB) STRIP=$(STRIP) \
>     --build=$(build) \
>     --host=$(host) \
>     --prefix=/usr \
>     --sysconfdir=/etc \
>     --localstatedir=/var
> 
> Build libdaemon and expat like:
> 
>     unset MAKEFLAGS && \
>     $(MAKE) -C $(objdir) all
> 
> Stage/install libdaemon and expat like:
> 
>     unset MAKEFLAGS && \
>     $(MAKE) -C $(objdir) DESTDIR=$(resultdir) install
>     $(RM) $(RMFLAGS) $(resultdir)/usr/lib/*.la
> 
> Configure avahi like:
> 
>     cd $(objdir) && \
>     $(srcdir)/configure \
>     CC=$(CC) AR=$(AR) RANLIB=$(RANLIB) STRIP=$(STRIP) \
>     CPPFLAGS="-I$(resultdir)../expat/usr/include \
>     -I$(resultdir)../libcap/usr/include" \
>     LDFLAGS="-L$(resultdir)../expat/usr/lib \
>     -L$(resultdir)../libcap/lib" \
>     LIBDAEMON_CFLAGS="-I$(resultdir)../libdaemon/usr/include " \
>     LIBDAEMON_LIBS="-L$(resultdir)../libdaemon/usr/lib -ldaemon" \
>     --build=$(build) \
>     --host=$(host) \
>     --disable-dbus \
>     --disable-gdbm \
>     --disable-glib \
>     --disable-gobject \
>     --disable-gtk \
>     --disable-manpages \
>     --disable-monodoc \
>     --disable-python \
>     --disable-qt3 \
>     --disable-qt4 \
>     --enable-libdaemon \
>     --with-distro=none \
>     --with-xml=expat \
>     --prefix=/usr \
>     --sysconfdir=/etc \
>     --localstatedir=/var

The challenge, as always, in a cross-compilation environment, is the notion
of:

A) Where the source lives (here, $(srcdir)).

B) Where the intermediate build results (following 'make all') live (here,
   $(objdir)).

C) Where the final build results are staged (following 'make install') to
   compile and link against prior to final firmware packaging (here
   $(resultdir)).

D) Where things actually get installed on the target system after packaging
   and installation (here, some relative component below $(resultdir)).

(A) and (B) seem to have no impact on the problem, since the issue is a
link-time one.

For (D), the '*.la' file accurately expresses the desired value,
'libdir=/usr/lib'.

However, the value of 'libdir=/usr/lib' therein is only partially correct
for (C),  as the 'usr/lib' is correct but '/' is incorrect, depending on
whether the context is (C) or (D).

Regards,

Grant Erickson