On 10/30/2009 01:19 PM, Philip A. Prindeville wrote: > Howdy. > > I'm new to the list, and a bit of a neophyte to using libtool (save your > groans). I'm the lead developer on the Astlinux distro, so I get to > dabble in a lot of OSS projects, unfortunately. > > I'm trying to fix the somewhat dated package libusb-0.1.12 (it can be > found at http://sourceforge.net/projects/libusb/files/). > > We're doing a modified buildroot cross-compilation under Linux (FC11 > x86_64 in my case) to build an image for a different version of Linux > (astlinux on an i586 Geode). > > The issue is this. > > When I build libusb, using a cross-compiler and telling gcc to use an > alternate prefix, sysroot, etc. libtool is invoked with -rpath /usr/lib > by the Makefile.am: > > http://libusb.svn.sourceforge.net/viewvc/libusb/tags/0.1.12/libusb/Makefile.am?view=markup > > > > as (in the generated Makefile): > > ... > exec_prefix = ${prefix} > ... > libdir = ${exec_prefix}/lib > ... > > libusb.la: $(libusb_la_OBJECTS) $(libusb_la_DEPENDENCIES) > $(LINK) -rpath $(libdir) $(libusb_la_LDFLAGS) $(libusb_la_OBJECTS) > $(libusb_la_LIBADD) $(LIBS) > libusbpp.la: $(libusbpp_la_OBJECTS) $(libusbpp_la_DEPENDENCIES) > $(CXXLINK) -rpath $(libdir) $(libusbpp_la_LDFLAGS) > $(libusbpp_la_OBJECTS) $(libusbpp_la_LIBADD) $(LIBS) > > > > The problem is that this is an early linkage on the build host, where > the eventual DESTDIR hasn't yet been specified, but the resultant > libusbpp.la ends up looking like: > > ... > # Directory that this library needs to be installed in: > libdir='/usr/lib' > relink_command="(cd /home/philipp/kernel/build_i586/libusb-0.1.12; /bin/sh > ./libtool --mode=relink > /home/philipp/kernel/build_i586/staging_dir/bin/i586-linux-uclibc-g++ -Os > -pipe -fomit-frame-pointer -march=k6-2 -fno-align-functions -fno-align-loops > -fno-align-jumps -fno-align-labels -iwithprefix /include -iwithprefix > /usr/include --sysroot=/home/philipp/kernel/build_i586/root > --sysroot=/home/philipp/kernel/build_i586/staging_dir -o libusbpp.la -rpath > /usr/lib -version-info 8:4:4 -release 0.1 -export-dynamic -lusb usbpp.lo > @inst_prefix_dir@)" > > > > Oddly, the resultant libusb.la doesn't have this same issue, even though > it also has the same -rpath ... sequence: > > ... > # Directory that this library needs to be installed in: > libdir='/usr/lib' > > > > Note the absence of the relink_command definition. > > And indeed, when the cross-compiled files are installed on the target > system, I get: > > pbx ~ # ldd /usr/lib/libusbpp-0.1.so.4.4.4 /usr/lib/libusb-0.1.so.4.4.4 > /usr/lib/libusbpp-0.1.so.4.4.4: > libusb-0.1.so.4 => /usr/lib/libusb-0.1.so.4 (0x00000000) > libstdc++.so.6 => /lib/libstdc++.so.6 (0x00000000) > libm.so.6 => not found (0x00000000) > libc.so.0 => /lib/libc.so.0 (0x00000000) > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000) > libm.so.0 => /lib/libm.so.0 (0x00000000) > /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) > /usr/lib/libusb-0.1.so.4.4.4: > libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00000000) > libc.so.0 => /lib/libc.so.0 (0x00000000) > /lib/ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x00000000) > pbx ~ # > > > So I'm not sure why the libusbpp.so contains references to host file: > > libm.so.6 > > and why libusb.so doesn't. > > Running ldconfig ... generates the following output: > > ldconfig: /usr/lib/libusbpp-0.1.so.4 appears to be for multiple libc's: > Invalid argument > ldconfig: /usr/lib/libusbpp-0.1.so.4.4.4 appears to be for multiple libc's: > Invalid argument > ldconfig: /usr/lib/libusbpp.so appears to be for multiple libc's: Invalid > argument > ldconfig: /usr/lib/libusbpp-0.1.so.4 appears to be for multiple libc's: > Invalid argument > ldconfig: /usr/lib/libusbpp-0.1.so.4.4.4 appears to be for multiple libc's: > Invalid argument > ldconfig: /usr/lib/libusbpp.so appears to be for multiple libc's: Invalid > argument > > > > I've been chasing this a couple of weeks, but frankly I'm no further > along and don't know where I should be looking. > > Any assistance is appreciated, and I can give out access to the build > host via .ssh DSA/RSA key. > > I'm attaching a trace of the entire build session. > > Thanks, > > -Philip > >
Ok, since this didn't elicit a response, I'll start with a couple of easier questions: (1) are there known issues with cross-compilation when it comes to the link vs. final relink? (2) why (in this case) are C and C++ programs being handled differently? Thanks, -Philip _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
