Re: Patch to make libtool support cross-compile

[Guido Draheim]

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-