[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Patch to make libtool support cross-compile
From: |
Guido Draheim |
Subject: |
Re: Patch to make libtool support cross-compile |
Date: |
Sat, 09 Mar 2002 17:08:49 +0100 |
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-