[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Debugging Libtool's Insistence on Sourcing a Library from /usr/lib R
From: |
Grant Erickson |
Subject: |
Re: Debugging Libtool's Insistence on Sourcing a Library from /usr/lib Rather Than LDFLAGS |
Date: |
Sat, 09 Feb 2008 11:46:50 -0800 |
User-agent: |
Microsoft-Entourage/11.3.6.070618 |
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