|
From: | Charles Wilson |
Subject: | Re: [PATCH] [mingw] Add cross-compile support to cwrapper |
Date: | Mon, 26 May 2008 19:11:43 -0400 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.14) Gecko/20080421 Thunderbird/2.0.0.14 Mnenhy/0.7.5.666 |
Roumen Petrov wrote:
# func_to_host_path arg[SNIP]# ARG is the path (on $build) that should be converted to # the proper representation for $host. The result is stored @@ -2546,11 +2553,28 @@ func_to_host_path () func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\ $SED -e "$lt_sed_naive_backslashify"` ;; + * ) + # Unfortunately, winepath does not exit with a non-zero + # error code, so we are forced to check stderr for an + # error message. On the other hand, if the command is not + # found, the shell will set an exit code of 127. So we + # must check for both, which explains the odd construction:+ func_to_host_path_winepath_stderr=`winepath -w "$1" >/dev/null 2>&1`+ func_to_host_path_winepath_exitcode=$? + if test "$func_to_host_path_winepath_exitcode" -eq 0 &&\ + test -z "${func_to_host_path_winepath_stderr}" ; then + func_to_host_path_tmp1=`winepath -w "$1"`+ func_to_host_path_result=`echo "$func_to_host_path_tmp1" |\+ $SED -e "$lt_sed_naive_backslashify"` + fi + ;;[SNIP]So it winepath fail to convert a build-system path it output only LF on standard output(stdout). I cannot confirm that exists relation: 'non-empty' stderr output and path-translation failure.My point of view is that check for 'empty' stdout is enough as indication for translation-failure.
The problem with that is, bash puts the following on stdout -- NOT stderr -- if it cannot find winepath:
bash: winepath: command not found So, at the very least, we have failure if either stdout is empty or exit code is nonzero Try replacing the section above with: * ) # Unfortunately, winepath does not exit with a non-zero # error code, so we are forced to check the contents of # stdout. On the other hand, if the command is not # found, the shell will set an exit code of 127 and print # *an error message* to stdout. So we must check for both # error code of zero AND non-empty stdout, which explains # the odd construction: func_to_host_path_tmp1=`winepath -w "$1" 2>/dev/null` func_to_host_path_winepath_exitcode=$? if test "$func_to_host_path_winepath_exitcode" -eq 0 &&\ test -n "${func_to_host_path_tmp1}" ; then func_to_host_path_result=`echo "$func_to_host_path_tmp1"|\ $SED -e "$lt_sed_naive_backslashify"` fi ;; And let me know if that works better for you.
Fine with the fail-back change in func_to_host_path .But I would like to note that this addition always lead to non-empty func_to_host_pathlist_result in func_to_host_pathlist. So I think that the then clause in check "if test -z "$func_to_host_pathlist_result" ; then" is reachable only if function argument $1 if empty.
Yes, and that's ok. It's to allow things to continue to work "as they are" even if we add additional $host/$build pairs to func_to_host_path[list], and those other pairs explicitly force empty return values.
About "# Now, add the leading and trailing path separators back" from func_to_host_pathlist: By default wine search in current directory and path-list like ";m:\..." is equal to "m:\...". Same for trailing separator.In this case the new code simplify script and it is fine with me.
Yes, but the case I'm thinking about, libtool converts two different paths: /path/to/destdir/inst/app and :/path/to/destdir/inst/lib:/path/to/builddir/.libs:and then joins the results. So, if we aren't very careful with the leading/trailing :, we'll end up with
C:\path\to\destdir\inst\appC:\path\to\destdir\inst\lib;C:\path\to\builddir\.libs ^^^ oops. -- Chuck
[Prev in Thread] | Current Thread | [Next in Thread] |