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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
