The patch http://www.kegel.com/libtool-cross-2.patch appears to fix libtool1.4d so it sets sys_lib_search_path_spec properly, which is probably required for cross-compiling programs that use libtool.
To test it, I created dummy cross-compiler mycc and linker myld which are just trivial wrappers around cc and ld, except that mycc --print-search-dirs prints paths that refer to /old instead of /, e.g. libraries: =/old/usr/lib/gcc-lib/i386-redhat-linux/2.96/:...:/old/usr/lib/ (/old on my machine is an old installation of linux.) To configure libtool, I created a small configure.in and Makefile.in, ran libtoolize, copied libtool.m4 to aclocal.m4 as instructed, ran automake --add-missing just to get install-sh etc., ran autoconf, and configured with CC=`pwd`/mycc LD=`pwd`/myld ./configure --build=pentium-unknown-linux --host=ppc-unknown-linux (the exact value for host doesn't matter as long as the processor is different). To verify whether libtool is configured properly, I run ./libtool --config | egrep 'LD|CC|sys_lib_search_path_spec' Before applying my patch, libtool1.4d --config outputs CC="/home/dank/foo/mycc" LD="/home/dank/foo/myld" sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" In other words, the current libtool 1.4d searches the system libraries instead of the libraries used by the specified compiler. After applying an earlier version of my patch, http://www.kegel.com/libtool-cross.patch, rerunning autoconf and configure, rerunning libtool --config | grep sys_lib output sys_lib_search_path_spec=" =/old/usr/lib/gcc-lib/i386-redhat-linux/2.96/ ... /old/usr/lib which looks correct except for that odd = in front. (There might be a similar bug in the mingw support in libtool, which also uses --print-search-dirs.) I poked around a bit, and that = appears to be present in the output of 'gcc --print-search-dirs' on gcc's after 2.95. Is it a bug in gcc, or just a strange feature? I modified the patch a bit to strip the = off. The resulting patch is http://www.kegel.com/libtool-cross-2.patch I'd appreciate hearing from anyone who's been trying to cross-compile programs built with libtool about whether this patch helps them. Thanks, Dan p.s. Here's the patch inline for convenience: --- libtool.m4.orig Sat Mar 9 07:28:58 2002 +++ libtool.m4 Sat Mar 9 15:30:52 2002 @@ -984,7 +984,20 @@ version_type=none dynamic_linker="$host_os ld.so" sys_lib_dlsearch_path_spec="/lib /usr/lib" -sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" +if test "$GCC" = yes; then + sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed -e +"s/^libraries: *=*//"` + if echo "$sys_lib_search_path_spec" | egrep ';' >/dev/null ; then + # if the path contains ";" then we assume it to be the separator + # otherwise default to the standard path separator (i.e. ":") - it is + # assumed that no part of a normal pathname contains ";" but that should + # okay in the real world where ";" in dirpaths is itself problematic. + sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed -e 's/;/ /g'` + else + sys_lib_search_path_spec=`echo "$sys_lib_search_path_spec" | sed -e +"s/$PATH_SEPARATOR/ /g"` + fi +else + sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" +fi need_lib_prefix=unknown hardcode_into_libs=no _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
