As pointed out by H. Lu in October ( http://mail.gnu.org/pipermail/bug-libtool/2001-October/002869.html ) and seconded by Guido ( http://mail.gnu.org/pipermail/bug-libtool/2001-October/002872.html ) libtool improperly searches /lib and /usr/lib when doing a cross-compile, which results in libraries from the build system leaking into the link (which results in programmers throwing rotten tomatoes at the screen).
You can see the essential problem in the current cvs version http://subversions.gnu.org/cgi-bin/cvsweb/libtool/libtool.m4?rev=1.249 It sets sys_lib_search_path_spec without asking the cross-compiler what its default system search path is. Following a suggestion by Guido, I posted a patch http://mail.gnu.org/pipermail/libtool/2002-March/006133.html that solved this problem for me. Guido liked the patch, but pointed out a bug. http://mail.gnu.org/pipermail/libtool/2002-March/006136.html I suppose the following is closer to correct: --- libtool.m4.orig Sat Mar 9 07:28:58 2002 +++ libtool.m4 Sat Mar 9 07:30:59 2002 @@ -984,7 +984,11 @@ 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 && test "$cross_compiling" = yes; then + sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | sed -e +"s/^libraries://" -e "s/:/ /g"` +else + sys_lib_search_path_spec="/lib /usr/lib /usr/local/lib" +fi need_lib_prefix=unknown hardcode_into_libs=no That stays closer to the original spirit of the code, and should fix the bug Guido pointed out. Comments? - Dan _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
