libtool
[Top][All Lists]
Advanced

[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 19:17:38 +0100

Es schrieb Dan Kegel:
> 
> Guido Draheim wrote:
> > ... you put the patch before the big case-series
> > for the target-platform, so I guess that the libpath will be
> > overridden immediately.
> 
> Only if the case statement below decides to override it.
> Linux doesn't.
> Putting it above the case statement is safer because it
> only changes the default path. It's also a more incremental
> change.   Unless you want to test all
> those odd platforms, we should go for the safer way, I think.

aaah, that's a good argument, to go the pragmatic way and let
the generalization trickle in on an incremental path. Well,
indeed I didn't know how to lead a discussion in favour of a
total generalization of the crosscompile case via a mailing
list, so this one is as good as it can get. Okay then, Dan,
I'm with you, let's put it in up front, before the case-block.

> 
> > 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).
> 
> OK, I can go for that.  (Incidentally, why egrep instead of grep?
> Aha, I see, because the original heuristic was from the mingw case.
> Sure you want to grep for just ; and not the drive letter, too?)
> 

yepp, I didn't like the egrep either, but I made the patch that
way to keep the change-level low, so the interest can focus to
the actual change. And yes, we only special-case for ";" and
nothing else (btw, I know some platforms that use an url-type
scheme for their pathspecs, i.e. my:drive:/mounted/here - they
use ";" as the pathsep too, but have "/" as the dirsep).

> Here's a patch that uses your heuristic,
> but avoids changing the value of sys_lib_search_path_spec for
> platforms that override the default.  This should fix cross-compile
> on linux, and not break [as many] odd platforms:

I support this one. Please, let's put this in ASAP. cheers, guido

> 
> --- libtool.m4.orig     Sat Mar  9 07:28:58 2002
> +++ libtool.m4.dan      Sat Mar  9 09:32:02 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
> 
> ---------------------
> 
> Later, if you trust the default value, you can try additional
> patches to remove the platform-specific overrides, e.g.
> 
> ---------------------
> 
> diff -au libtool.m4{.orig,.dan}
> --- libtool.m4.orig     Sat Mar  9 07:28:58 2002
> +++ libtool.m4.dan      Sat Mar  9 09:37:31 2002
> 
> @@ -1089,18 +1102,6 @@
>      ;;
>    yes,mingw*)
>      library_names_spec='${libname}`echo ${release} | sed -e 
> 's/[[.]]/-/g'`${versuffix}.dll'
> -    sys_lib_search_path_spec=`$CC -print-search-dirs | grep "^libraries:" | 
> sed -e "s/^libraries://"`
> -    if echo "$sys_lib_search_path_spec" | [egrep ';[C-Z]:/' >/dev/null]; then
> -      # It is most probably a Windows format PATH printed by
> -      # mingw gcc, but we are running on Cygwin. Gcc prints its search
> -      # path with ; separators, and with drive letters. We can handle the
> -      # drive letters (cygwin fileutils understands them), so leave them,
> -      # especially as we might pass files found there to a mingw objdump,
> -      # which wouldn't understand a cygwinified path. Ahh.
> -      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
>      ;;
>    yes,pw32*)
>      library_names_spec='`echo ${libname} | sed -e 's/^lib/pw/'``echo 
> ${release} | sed -e 's/[.]/-/g'`${versuffix}.dll'
> 
> ------------------
> 
> but that's something that needs to be tested on each platform.
> 
> - Dan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]