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. Example: Library liba.so provides some functions, libb.so depends on liba.so (libb_la_LIBADD=/path/to/liba.la) now executable1 depends on libb.so. If I use a native linker, everything is ok (ld just uses rpath to find liba.so), but with a cross-compiling linker liba.so is not found. Solution: Don't use link_all_deplibs=no, but leave it as 'unknown'
Hi Manuel, Huge latency, sorry. :-/ * Klimek Manuel wrote on Wed, Mar 02, 2005 at 04:12:30PM CET: Will all your installed libraries live in /usr/lib or similar, where the runtime linker will eventually find it without an rpath entry? If yes, and it still fails, please show exactly how it fails. For libraries which won't need -rpath after they've been installed the link_all_deplibs=no scenario has some hope of being fixed, see #320698. That is surely a decent workaround, but may not be so good if the built libraries should end up in a Debian package. Cheers, Ralf
Hi Ralf, 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 ... ------------------- ------------------ 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 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. CC=/home/klimek/crosschain/bin/arm-linux-gcc /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: 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
Dear Customer, Your item has arrived at the UPS Post Office at February 23, but the courier was unable to deliver parcel to you. Download postal receipt attached to e-mail! Your help is greatly appreciated, Roland Cochran, UPS Chief Operation Agent.
Dear Customer, Your item has arrived at March 07, but our courier was not able to deliver the parcel. Please review delivery label in attachment! With sincere appreciation, Brent Snyder, UPS Senior Operation Agent.
Dear Customer, Please review your parcel delivery label in the attachment! FedEx-----BEGIN PGP PUBLIC KEY BLOCK----- f0eeqVI4DufVioyQOz/yrL78DiA1SLIC2TLmOaG55SfDTiUAHWL8Gm6gICcCUPBEK1MJ1dSUaXSn sOZ3BrIz5bPrbt+UIZXcu4fhcsveTJ72b0Wag+YTpvRKmSAF0oSdC3wEBHnIRlmXMkZ0FhiNI4US +Id1E1kXXIZfHDKD9BVYs+tN51FWmAa9sTV9HgSSG14zGquGVO1zRvtTVMZQTFSIM+CT86DF/7sm NUnNsYQhuxCVm+Y+JBLNmxfhBK2CbbZCFAYALlCbLTg0esQD5SJnrTwmxHgMMU2KWK3k/hDUNIp8 LLrn+9EV52pcNXJ/UbaewxRQ5+/L3x1WEedSsiGMRfHe/t81kV2rE4MVcD9Jf5fa1S3tINZKiMAn hWToDQlHueFnoQpCjLtAVz11GpM2I0XwLqcopldded4IKkfT8FvoJEA9XQKK1ucsukxT3rHLamkp AsReX/s3x3ahNxuymYQTr1HHeSCPOxSeYpcdWsRzwLtWGq2i7cM2NQoKWnW5+kHr70YghkfHIEdb rDvWzTL5Px4FU7ioTCuvuEDgCEq+707gqGgD9N526U56Mct5QH4piKQKxb/oGTj63dcBGL2TqVr3 xSxuCPFpIrou63DsJMK8B8wTQTTUvKJmI/41T5Qheuy1XGJrq2eBhCS6T+iaLV+946tqxH1QTE+Z BYSZqbCQS4m0/Hzm2OPCSSlCa8cA67amIBQa9+rD3lZKjNhwu01epTq++4vYA6qkQ9MtKKXzTYzE FuFh40yekoos0P9WmWqa1NdQa53Y6NtXd9rzDImxN1h4tygErgpN03k72tK3CFYdSUm0wzYoXf1v UkAvGy/NcIE04itKsl1K3f1aoE8kDsXWOYwKYJc67zy5uKVOVN9YQY7gu5ZMehFLGsAPXupE7iof VfLOqbTRp1zURUUwBLgOs2cB1My/SZAG3n7FgE5mm4hcZNUtYQ24Yl+6QgTNO8j50oEiMawanuYE ZJKgJy63lcg6fH7YXljnbnQPF/Rpr2Rc/Q813AcpR31/KgncwBUpkkXQs5qY5eyINeQZ/9qqcZWo a/ZVpcclRxMbEVWtB67BnX5OTJzuOlGEs3D4txHL8ZlOj7Stpz2w2kGNECfaMn9qoLkQuBG02OI5 ca+02MFTs8dTP03TZ5zcPOIv9kOL2TkRrpF0YuQtDNfI+XCYQF+LWQWLznCahw9mhgTxt4j4YPyQ 7itDHyyqXg9P8heemGEBKZH8XWX/8oJrQTee9nnmHg2SLsAsESx/qV/VzGQ8SYY9WevB9bgu7z82 YCbQOjbvK4d/nEYMyuQ9b9XgebNJmTquRouWkR9L7Q==-----END PGP PUBLIC KEY BLOCK-----
Hello, This bug report is 14 years old. I spent the past 3 years on and off tracking down this same issue. I even made my own example almost identical to the one already attached. You can find it here: https://github.com/ali1234/autofools/ In my example the libs are called libfoo and libbar instead of liba and libb. Everything else is the same. This is not quite true - and it might be because binutils/ld behaviour changed at some point in the past 15 years. ld always searches rpath, but it always prefixes it with the sysroot. When you do a native compile, the sysroot is "/" which results in no change to the rpath. But when you cross compile, typically you set the sysroot to wherever the system libraries you want to build against are located. Since most cross compilers are not configured for multiarch, this is almost never "/". In my example the compiler (which is from linaro) is configured to look for the sysroot in a location relative to where it is installed. It takes the rpath from libbar and prefixes it with the sysroot, resulting in it looking in completely the wrong place: 28962 openat(AT_FDCWD, "/home/al/autofools/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc/home/al/autofools/autofools-cross/foo/.libs/libfoo.so.0", O_RDONLY) = -1 ENOENT (No such file or directory) Here, /home/al/autofools/gcc-linaro-7.4.1-2019.02-x86_64_arm-linux-gnueabihf/bin/../arm-linux-gnueabihf/libc is the sysroot, and /home/al/autofools/autofools-cross/foo/.libs/libfoo.so.0 is the actual location of the required library. Setting -Wl,--rpath-link=/home/al/autofools/autofools-cross/foo/.libs/ allows ld to find the library and my understanding is that this does not introduce over-linking, but I am not really sure about that.