Hi Ralf, > * Klimek Manuel wrote on Wed, Mar 02, 2005 at 04:12:30PM CET: > > > > The libtool.m4 file which comes in this release differs from the > > upstream libtool.m4 for libtool-1.5.6. > > > > Especially the diff > > 5009,5011d5004 > > < linux*) > > < _LT_AC_TAGVAR(link_all_deplibs, $1)=no > > < ;; > > > > Sets link_all_deplibs to no on linux targets. Now the > problem is, that > > gnu-ld doesn't use rpath on cross-compilation targets. Thus > the link > > process fails with unresolved symbol messages when > cross-compiling if > > dependent libraries must be linked in. > > Will all your installed libraries live in /usr/lib or > similar, where the runtime linker will eventually find it > without an rpath entry?
yes, they will, but runtime linkage is (for me) not the problem. Here's an example project that shows what exactly fails: (you'll need autoconf, automake, libtool and stuff to build) Tested on debian sid, but should work on sarge ... > tar xvzf miniproject.tar.gz > cd miniproject > make -f Makefile.autoconf Native compilation: ------------------- > mkdir native > cd native > ../configure --prefix=`pwd`/install > make install > native.output > cd ../ Cross compilation: ------------------ > /home/klimek/crosschain/bin/arm-linux-gcc -v Reading specs from /home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain/lib/gcc/arm-l inux-uclibc/3.4.3/specs Configured with: /home/klimek/stuff/toolchains/mppl-terminal-voeb/build/toolchain/buildro ot/toolchain_build_arm/gcc-3.4.3/configure --prefix=/home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain --build=i386-pc-linux-gnu --host=i386-pc-linux-gnu --target=arm-linux-uclibc --enable-languages=c,c++ --enable-shared --disable-__cxa_atexit --enable-target-optspace --with-gnu-ld --disable-nls --enable-sjlj-exceptions Thread model: posix gcc version 3.4.3 > /home/klimek/crosschain/arm-linux-uclibc/bin/ld --version GNU ld version 2.15.91.0.2 20040727 Copyright 2002 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. > mkdir cross > cd cross > ../configure --prefix=`pwd`/install --host=arm-linux CC=/home/klimek/crosschain/bin/arm-linux-gcc > make install > cross.output libtool: install: warning: relinking `libb.la' /home/klimek/stuff/toolchains/mppl-terminal-voeb/toolchain/lib/gcc/arm-l inux-uclibc/3.4.3/../../../../arm-linux-uclibc/bin/ld: warning: liba.so.0, needed by ../libb/.libs/libb.so, not found (try using -rpath or -rpath-link) ../libb/.libs/libb.so: undefined reference to `a' collect2: ld returned 1 exit status make[1]: *** [exec] Error 1 make: *** [install-recursive] Error 1 Explanation: when gnu-ld links exec native, it will search the rpath in the library to resolve symbols recursively. when gnu-ld links exec for cross compilation, it will not use rpath (probably because it can't know the runtime linker that will be used). Debian libtool has the diff: > > Especially the diff > > 5009,5011d5004 > > < linux*) > > < _LT_AC_TAGVAR(link_all_deplibs, $1)=no > > < ;; This means for linux targets the link_all_deplibs flag will always be "no". If this variable is set to "no", libtool will not change it. So gnu-ld fails for cross-compilation as in the example above. Now if debian packages are cross-built, as far as I understood the problem all upstream Makefile.am's have to be patched to include all dependencies, which would be the same as not applying the mentioned patch. Otherwise packages can not be cross-compiled. Solutions I see: a) patch gnu-ld to find out if rpath can be used to resolve dependant symbols b) set link_all_deplibs to "yes" for cross-compilation Cheers, Manuel
miniproject.tar.gz
Description: miniproject.tar.gz
