Es schrieb Dan Kegel: > > 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? >
'had a closer look - you put the patch before the big case-series for the target-platform, so I guess that the libpath will be overridden immediately. Secondly, the sed-pathsep should be done with an heuristic that was felt correct on the mailinglist some time ago (and it is needed, as a win32-gcc might spit out a different pathsep in its -print-search-dirs than the current runtime (and target) personality might suggest). here is what mine looks like, I did even experiment with an extended else-part for non-gcc cross-mode that searches for the relevant lib-dirs in the build system using some heuristics, but I did not have a chance to check that one thoroughly, so I leave it out for this discussion. @@ -1410,7 +1399,39 @@ dynamic_linker=no ;; esac -AC_MSG_RESULT([$dynamic_linker]) + +if test "$build_cpu-$build_os" == "$host_cpu-$host_os" ; then + AC_MSG_RESULT([$dynamic_linker]) +else + 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 + AC_MSG_RESULT([$dynamic_linker (crossgcc)]) + else + AC_MSG_RESULT([$dynamic_linker (cross)]) + fi +fi test "$dynamic_linker" = no && can_build_shared=no ])# AC_LIBTOOL_SYS_DYNAMIC_LINKER -- guido http://freespace.sf.net/guidod GCS/E/S/P C++/++++$ ULHS L++w- N++@ d(+-) s+a- r+@>+++ y++ 5++X- _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
