Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Den 2010-08-29 23:30 skrev Roumen Petrov: Peter Rosin wrote: Den 2010-08-27 00:27 skrev Roumen Petrov: Ralf Wildenhues wrote: Hi Charles, [SNIP] + func_wine_to_win32_path_result=$1 + if test -n $1; then +# 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: Starting from wine 1.3.1 wine path always output paths: I have been reading the git source of winepath, and it definitely has code paths which output an empty result when certain things fail (or rather, a single newline for every path/file it fails to convert), so saying that it always output paths is not entirely correct. Lets wine is correctly configured (Z: drive is linked to the file system root): $ cd $WINEPREFIX/dosdevices $ winepath -w `pwd` Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices Now lets remove link: $ rm z: $ winepath -w `pwd` \\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices So sed should remove leading //?/unix This failures are probably comping from inside wine (no mention of //?/unix or \\?\unix in the winepath source), so probably won't be seen as failure by winepath. But, if you silently remove \\?\unix, then you'll end up with a path that is not complete with a drive letter. I think any \\?\unix prefix should be filed as a failure... Peter, are you reading this? Looks like a TODO item for automake/lib/compile. ;-) Yes, I'm reading this :-) Patches to compile (and ar-lib) to follow when the dust settles... Cheers, Peter FYI http://bugs.winehq.org/show_bug.cgi?id=13265 Ok, I have read that and studied the Wine source a bit more and see where \??\ is transformed into \\?\. So, sorry for the false accusation regarding copy-paste vs. retyping in my other reply... I have now prepared a patch for compile and ar-lib in automake... Cheers, Peter
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Den 2010-08-28 08:57 skrev Charles Wilson: Rename file/path conversion functions * TODO: Document QoI issue with file name conversion functions. * Makefile.am (TESTS_ENVIRONMENT): Renamed cache variable lt_cv_to_host_path_cmd to lt_cv_to_host_file_cmd; Renamed environment variable to_host_path_cmd to to_host_file_cmd. * tests/testsuite.at: Ditto. You missed one instance here. Pushed the attached as obvious... Cheers, Peter From 7f41a19bc95d266cf0761bdad21e1821335cd442 Mon Sep 17 00:00:00 2001 From: Peter Rosin peda@lysator.liu.se Date: Sun, 29 Aug 2010 18:17:45 +0200 Subject: [PATCH] Fix typo when renaming path conversion functions. * tests/testsuite.at: Ensure to_host_file_cmd is passed as a variable setting on the configure line for (new testsuite) tests. Signed-off-by: Peter Rosin peda@lysator.liu.se --- ChangeLog |6 ++ tests/testsuite.at |2 +- 2 files changed, 7 insertions(+), 1 deletions(-) diff --git a/ChangeLog b/ChangeLog index 6650889..c6c2447 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,9 @@ +2010-08-29 Peter Rosin peda@lysator.liu.se + + Fix typo when renaming path conversion functions. + * tests/testsuite.at: Ensure to_host_file_cmd is passed as a + variable setting on the configure line for (new testsuite) tests. + 2010-08-29 Ralf Wildenhues Ralf.Wildenhues@gmx.de Work around yet another shell quoting portability issue. diff --git a/tests/testsuite.at b/tests/testsuite.at index 5818060..a20e074 100644 --- a/tests/testsuite.at +++ b/tests/testsuite.at @@ -37,7 +37,7 @@ for tool in ACLOCAL AUTOHEADER AUTOCONF AUTOMAKE AUTORECONF; do done export ACLOCAL AUTOHEADER AUTOCONF AUTOMAKE AUTORECONF eval `$LIBTOOL --config | grep '^EGREP='` -eval `$LIBTOOL --config | $EGREP '^(host|host_os|host_alias|build|build_alias|to_host_path_cmd)='` +eval `$LIBTOOL --config | $EGREP '^(host|host_os|host_alias|build|build_alias|to_host_file_cmd)='` configure_options=--prefix=/nonexistent if test -n $host_alias; then configure_options=$configure_options --host $host_alias -- 1.7.1
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/29/2010 12:21 PM, Peter Rosin wrote: Den 2010-08-28 08:57 skrev Charles Wilson: Rename file/path conversion functions You missed one instance here. Pushed the attached as obvious... Thanks. -- Chuck
git and branches (was: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6))
Maybe a bit more explanation: * Ralf Wildenhues wrote on Sat, Aug 28, 2010 at 07:22:42AM CEST: * Charles Wilson wrote on Sat, Aug 28, 2010 at 07:10:25AM CEST: On 8/27/2010 3:47 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST: However, once I have finished the requested changes above and the rebasing (plus whatever comes of the four open ***QQQ***uestions), I might ask for a 12 hour halt on updates to master so I can run those tests, if that's ok? Why should you need the halt? If there are new pushs in the meantime, you just merge origin/master into your master, and push. Doesn't that mess up the linear history of commits in the upstream master? Well, yes, if you want to call it messing up, that is. From git's perspective, origin/master and master are not the same branch in your repository. Just that most of the time, you use fast-forward or rebase when getting the changes from the former into the latter. With git, branch names are not permanent. branches are merely movable named pointers into some DAG, and when you delete a branch, all you delete is the named pointer. The only bit where branch names become permanent is in the text of the (automatically generated) log entries for merge commits. And these are just for humans to read and digest, so you could even change them after a merge (with commit --amend) if you haven't made that merge public. In that way, whether your master tracks origin/master is only relevant for 'git pull' (namely, which remote branch to merge or rebase against) and 'git status' messages. In the case above, you would of course do fetch and then merge rather than fetch and then rebase (not sure if your pull is configured to rebase rather than merge). FWIW, I've come to never use pull, simply because it confuses me having to think about which way was configured as default (merging or rebasing). The branch concept is in contrast to some other dVCS where branch names somehow permanently describe (possibly overlapping) subgraphs of the full history graph. Cheers, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* Charles Wilson wrote on Sat, Aug 28, 2010 at 08:57:04AM CEST:
This is just an FYI. The take-away here is that I did go ahead and
rename all the functions to
func_convert_{file|path}_X_to_Y
and moved them to just before func_mode_compile. I changed all comments
and function names to use the 'file' (or file name) and 'path'
terminology, instead of the original 'path' and 'pathlist' terminology.
Thanks.
Peter is going to hate me.
Well, since I'm sort-of responsible for the extra work, I volunteer to
rebase Peter's patches if that helps him. Peter, if you accept, please
either make your tree public or send me a git bundle that contains all
the patches.
Cheers,
Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/28/2010 2:57 AM, Charles Wilson wrote: Ok, I've addressed all of the review comments, including the results of the four ***QQQ***estions. Quick-N-Dirty spot testing on native cygwin, native mingw, cygwin-mingw, linux-mingw, linux-cygwin all look good, so I'm about to rebase on my private branch. rebased, tested, merged, and pushed. I renamed the commit to better reflect the actual content (after 7 revisions, it shifted a bit). See [PATCH] [cygwin|mingw|cross-compile]: Path conversion support http://article.gmane.org/gmane.comp.gnu.libtool.patches/10408 -- Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Den 2010-08-27 00:27 skrev Roumen Petrov: Ralf Wildenhues wrote: Hi Charles, [SNIP] + func_wine_to_win32_path_result=$1 + if test -n $1; then +# 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: Starting from wine 1.3.1 wine path always output paths: I have been reading the git source of winepath, and it definitely has code paths which output an empty result when certain things fail (or rather, a single newline for every path/file it fails to convert), so saying that it always output paths is not entirely correct. Lets wine is correctly configured (Z: drive is linked to the file system root): $ cd $WINEPREFIX/dosdevices $ winepath -w `pwd` Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices Now lets remove link: $ rm z: $ winepath -w `pwd` \\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices So sed should remove leading //?/unix This failures are probably comping from inside wine (no mention of //?/unix or \\?\unix in the winepath source), so probably won't be seen as failure by winepath. But, if you silently remove \\?\unix, then you'll end up with a path that is not complete with a drive letter. I think any \\?\unix prefix should be filed as a failure... Peter, are you reading this? Looks like a TODO item for automake/lib/compile. ;-) Yes, I'm reading this :-) Patches to compile (and ar-lib) to follow when the dust settles... Cheers, Peter
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Den 2010-08-27 08:25 skrev Peter Rosin: Den 2010-08-27 00:27 skrev Roumen Petrov: Lets wine is correctly configured (Z: drive is linked to the file system root): $ cd $WINEPREFIX/dosdevices $ winepath -w `pwd` Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices Now lets remove link: $ rm z: $ winepath -w `pwd` \\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices So sed should remove leading //?/unix This failures are probably comping from inside wine (no mention of This failure is probably coming (fat fingers today...) //?/unix or \\?\unix in the winepath source), so probably won't be seen as failure by winepath. But, if you silently remove \\?\unix, then you'll end up with a path that is not complete with a drive letter. I think any \\?\unix prefix should be filed as a failure... Hmmm, I dug deeper into the wine source and wine_unix_to_nt_file_name in the dlls/ntdll:path.c file seems to sometimes prefix the path with \??\unix (with two question marks), so you seem to have mistyped the above (and not copy-pasted an actual session as I originally thought). It also seems we can forget about the forward slash variant? But I'm not regularly running wine, so someone who does should chime in with verification. Cheers, Peter
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* Charles Wilson wrote on Fri, Aug 27, 2010 at 06:35:31PM CEST:
It appears the problem is that the mdemo{2}_static.exe tests don't work,
when mdemo{2}-conf.test is used. They DO work when mdemo-static.test is
used (there is no mdemo2-static.test).
Now, this is a little disturbing, since my -dlpreopen was supposed to
have fixed this;
Would be good to fix, yes. On *nix, I'd be suggesting git bisect now,
no idea if you can stand the wait on w32 though. At least you should be
able to speed it up significantly with something like
make check TESTSUITEFLAGS=-V TESTS=all the mdemo ones
in the bisection script, and with some luck, such a script can run
unsupervised ...
linux-mingw cross
==
linux-mingw (old tests): 2 of 100 FAIL, 6 SKIP
FAIL: tests/demo-hardcode.test
FAIL: tests/depdemo-relink.test
Don't know if these are regressions or not; will recheck without
this patch.
The real bug here is that the relink tests (both of them, actually)
should be skipped when cross-compiling, because you have no business
trying to execute the $host executable.
I kind of agree. Can we make it so that it is tested, but when the test
programs don't behave as expected, and we cross-compile, we SKIP instead
of FAIL? Or is even trying to execute the broken programs a sin, in
which case we should SKIP outright? Thanks.
Okay, so I rebuilt my linux-cygwin compiler after asking for help on
cyg...@. This one does NOT have sysroot support (one thing at a
time...) but it DOES work. I was able to build not just hello world in
C++, but also to rebuild cygwin itself, and the new DLL worked fine.
So, re-running the linux-cygwin tests, I got:
linux-cygwin (old tests): 2 of 91 FAIL, 33 SKIP
FAIL: tests/demo-hardcode.test
FAIL: tests/demo-relink.test
linux-cygwin (new tests): 59 as expected. 58 skipped.
Three notes:
1) With *this* compiler, there are no regressions with this patch. I
got the same results both with and without this patch.
Cool.
2) The failures on linux-cygwin in the old testsuite are similar to the
failures on linux-mingw in the old testsuite (not the same;
linux-mingw fails depdemo-relink; linux-cygwin fails demo-relink).
3) EVERY new test that FAILED when using my broken compiler was
actually SKIPPED when using the new working one. So, oddly, with the
broken compiler, the testsuite seems to be confused as to whether the
build is a crossbuild or not.
However, I won't be looking in to this further until after I rebuild my
toolchain (again) with sysroot support; probably next week.
OK.
So, to sum up all of these test runs: it does not appear that ANY of the
failures experienced are regressions, or are due to anything associated
with THIS patch, on any of the platforms or configurations I have tested.
Great.
I still need to do the cygwin-mingw (lie) case, but I think I will
save that until after I resolve the code comments.
OK.
Thanks!
Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Another questions regarding this patch: Do you know whether all of the conversion functions are idempotent (f(f(x)) = f(x))? IOW, when the user passes names already converted, do we do the right things in all cases? Thanks, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
--- a/Makefile.am
+++ b/Makefile.am
@@ -528,7 +528,8 @@ TESTS_ENVIRONMENT = MAKE=$(MAKE) CC=$(CC)
CFLAGS=$(CFLAGS) \
CXX=$(CXX) CXXFLAGS=$(CXXFLAGS) CXXCPP=$(CXXCPP) \
F77=$(F77) FFLAGS=$(FFLAGS) \
FC=$(FC) FCFLAGS=$(FCFLAGS) \
-GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS)
+GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) \
+lt_cv_to_host_path_cmd=$(to_host_path_cmd)
I don't understand why this change should be necessary. In your
testing, you describe that most setups set a correct to_host_path_cmd
themselves. For the other(s), you already describe
export lt_cv_to_host_path_cmd=override
./configure ...
make all check
That should be sufficient without the above patch, no?
Well, IF you *export* that value before running configure, AND run the
tests from the same shell in which that value is exported, then sure,
that is all you need. (I think. It's been over two years since I wrote
this patch...)
However, we need to ensure that the tests work even if you run them from
a different shell that the one you configured with. I realize we don't
tend to do this for *all* possible cache values that the end-user might
override, but this one (and the one Peter added) are special, because
the documentation is going to talk about them explicitly. We're
actually going to *recommend* that certain classes of users override
these particular cache values. That makes them different from all the
other lt_cv_* variables someone might override.
It's best to avoid surprises, in that case.
Anyway, I reviewed all of the past discussion, and I found where this
was introduced: it was the addendum to version 3:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html
Now, while I admitted uncertainty back then about the Makefile.am
change, I recorded no other notes about the testsuite.at changes or why
I thought they were necessary. I do remember originally implementing it
without those two changes, and then having to add first the
Makefile.am change, and then the testsuite.at change, before I could get
things to work. But, sadly, I no longer remember exactly WHAT the
failure mode was (maybe it had to do with the tests that re-run other
tests, like max_cmd_length?)
I'll try it without both changes (but with lt_cv_* exported in the
current shell) and see what happens.
***QQQ***
(above discussion)
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2775,166 +2775,595 @@ fi\
}
+
+# PATH CONVERSION HELPER FUNCTIONS #
+
Believe it or not, the GNU Coding Standards ask us to name things file
name that which are files, and path those which are colon-separated
(or $PATH_SEPARATOR-separated). I'll close my eyes now on this issue,
because I see hundreds of instances of it in this patch, so that'd be a
TODO item.
It's not a difficult thing to do, and would be purely mechanical. I can
put that on the queue for right after (or even before) the promised docu
patch.
It needs to happen before the release, because the docu will recommend
that certain users set lt_cv_to_host_path_cmd (ok,
lt_cv_to_host_file_name_cmd) to the name of one of these functions. If
we're going to change the name of the functions, we better do it before
we document them.
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
Might want to move this variable outside to just initialize it once?
It's global anyway. Maybe even general.m4sh.
It would make sense in general.m4sh. OK.
+func_wine_to_win32_path_tmp=`winepath -w $1 2/dev/null`
+if test $? -eq 0 test -n ${func_wine_to_win32_path_tmp}; then
I'll just note that some shells ((d?)ash 0.2) fail to propagate the exit
status of an assignment. No need to change the code, but users should
have a decent shell for this.
OK. I remember one of the earlier iterations actually invoked the
winepath command twice...I don't remember why, but maybe it was related.
Most shells -- especially on x86 linux where wine would actually be
available -- are decent, tho.
+ func_wine_to_win32_path_result=`$ECHO $func_wine_to_win32_path_tmp |
+$SED -e $lt_sed_naive_backslashify`
+else
+ func_wine_to_win32_path_result=
The way this is coded, correctness relies on the fact that all code
paths that invoke this function do eventually check for non-emptiness
of the result.
Yes. That is documented:
# ARG is the $build path to be converted to win32 format.
# result is available in $func_wine_to_win32_path_result
# result is empty on error (or when arg is empty)
+func_wine_to_win32_pathlist_oldIFS=$IFS
IFS is saved and restored always to the same value in libtool, AFAIK,
so a short variable name should suffice completely.
Ack.
+IFS=:
+for func_wine_to_win32_pathlist_f in $1; do
+ IFS=$func_wine_to_win32_pathlist_oldIFS
+ if test -n
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/26/2010 5:20 PM, Charles Wilson wrote: On 8/26/2010 4:18 PM, Ralf Wildenhues wrote: Then, please just move the new functions where Peter needs them, if they really need moving, that is. I deliberately placed them after func_compile and before func_link, for speed-of-parsing reasons. Obviously libtool is used to compile object code much more often than it is used to link (since every linked result requires one or more, sometimes many more, objects) -- so moving these functions ahead of func_compile will impact speed. How much? Don't know; I'll try to generate some numbers. OTOH, it is absolutely *required* to move them where Peter wants them, since he /must/ use translate some paths if func_compile is to work, with MSVC. So...we have to pay the price regardless. I tested using 'ncurses' -- which conveniently is built using the system installed libtool script, rather than including ltmain.sh etc in its own configury. The times below are for a complete 'make' (after configure has already run) -- so it includes a lot more than just how fast does libtool --mode=compile go. But, the ONLY difference between the two is the relative position of the conversion functions within the libtool script, so any time differences should be attributable solely to that change. Original: real25m3.886s user6m24.620s sys 11m13.787s With the functions moved ahead of func_mode_compile: real24m34.235s user6m30.590s sys 11m23.878s Statistics: 69 executables linked 6 libraries (dlls) linked 654 objects (325 pic, 329 non-pic) So, when compiling about 325 source code files, the new function order cost 5 seconds of user time and 10 seconds of system time, total. That's 1/20th of a second slower per file, under: cygwin-1.7.6-1 bash-3.2.51-24 On a 1.67GHz Core 2 Duo machine running Vista. -- Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/27/2010 12:54 AM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Thu, Aug 26, 2010 at 11:20:48PM CEST:
Also: I've said this before, but we can't use the m4
function_replace magic because we need to retain the ability for
users to override the choice of $func_to_host_path_cmd. This is
critical for the 'cygwin-mingw (lie)' use case, which is VERY
common for the gcc developers.
Do you need an override at 'make' time or does one at configure time
suffice?
I'm not sure. I thought we needed the override at make time, but this
facility is here specifically to support a use case that *I don't
use*. I just really really really don't want to break the scheme used
by Danny and others when building gcc (even if Danny has now hung up his
gcc mingw maintainer hat).
It's possible that a configure-time-only override is sufficient.
Because if the latter (which I'm assuming), then from my POV the above
is just a statement that function_replace is not good enough for your
needs, not one it cannot be done.
Well, sure: if I thought, at the time, that configure-time-only was
sufficient, I wouldn't have said we can't. I was assuming that we
needed make-time-override capability; IF that is true, then you really
don't want to get into the situation where, at make-time, the user sets
lt_cv_to_host_path_cmd=a_func_we_did_not_emit.
OTOH, if configure-time-only is sufficient, then you really don't need
lt_cv_to_host_path_cmd at all. You just replace the guts of
func_to_host_path() itself. But that's rather a big change, and I
really don't want to go there right now -- especially as I'm not sure of
the answer to the at-configure-time-only or at-make-time question.
I think that question will have to be deferred until all this stuff is
merged, with the make-time-override capability, and then we let folks
(like Danny) get used to it. THEN we ask hey, would it be ok if you
could only modify the file/path conversion schema at configure time,
rather than at make time?
OTOH, as a follow-on patch after 2.2.next, we could implement an
explicit N+M scheme just so that any future extensions -- which I
can't actually foresee -- could hook in scalably.
Oh no, please not code which already sets out as dead code.
No, it wouldn't be dead code. Basically, you'd have
from_$build (actually, we would NOT really implement
any of these; see below)
to_$host== what they are now
There were be TWO variables lt_cv_from_build_cmd and lt_cv_to_host_cmd,
but only one function would ever eval them:
generic_build_to_host() {
$from_build_cmd $1
$to_host_cmd $from_build_cmd_result
generic_build_to_host_result=$to_host_cmd_result
}
But, at present, $from_build_cmd would *always* be assigned to
func_convert_noop.
Everywhere we currently do $to_host_cmd ..., you do
generic_build_to_host ... instead.
It's not dead code -- but it's *useless* code, right now, since with
the weird w32 platforms, you'd be calling $from_build_cmd
(func_convert_noop) uselessly.
If there is
a need for more translations, then maybe, but then I'd suggest there'd
be an effort to get as many of the w32 translators under the same hood
as possible.
I've reworded this discussion and put it into TODO, but don't plan to
address it any more than that. Status quo for now.
--
Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/27/2010 2:01 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Aug 27, 2010 at 06:35:31PM CEST: Now, this is a little disturbing, since my -dlpreopen was supposed to have fixed this; Would be good to fix, yes. On *nix, I'd be suggesting git bisect now, no idea if you can stand the wait on w32 though. At least you should be able to speed it up significantly with something like make check TESTSUITEFLAGS=-V TESTS=all the mdemo ones in the bisection script, and with some luck, such a script can run unsupervised ... The real bug here is that the relink tests (both of them, actually) should be skipped when cross-compiling, because you have no business trying to execute the $host executable. I kind of agree. Can we make it so that it is tested, but when the test programs don't behave as expected, and we cross-compile, we SKIP instead of FAIL? Or is even trying to execute the broken programs a sin, in which case we should SKIP outright? Thanks. I think they should be SKIPPED always. The test actually tries to arrange things so that the executable fails, by hiding its dependent DLLs. Well, on cross, we fail automatically 'cause we can't run the $host exe, so we PASS that part of the test -- but for the wrong reason. And, because the output from the failure is not what we expect...sometimes our failure results in a SKIP or a FAIL. And sometimes we ARE able to run the $host executable (cygwin-mingw, linux-w32 with binfmt) and things just get really hairy. It's just not reliable. SKIP 'em. -- Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* Charles Wilson wrote on Fri, Aug 27, 2010 at 10:23:31PM CEST: Original: real25m3.886s user6m24.620s sys 11m13.787s With the functions moved ahead of func_mode_compile: real24m34.235s user6m30.590s sys 11m23.878s So, when compiling about 325 source code files, the new function order cost 5 seconds of user time and 10 seconds of system time, total. That's 1/20th of a second slower per file, under: cygwin-1.7.6-1 bash-3.2.51-24 On a 1.67GHz Core 2 Duo machine running Vista. Yes, but there is a significant speedup in real time!? That makes little sense, unless the system was busy doing other things also, for the first run. 5% sucks a bit, fixing that should be a TODO item. Thanks for doing the measurements, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
I'm ok with everything in this.
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/27/2010 5:48 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Aug 27, 2010 at 10:23:31PM CEST: Original: real25m3.886s user6m24.620s sys 11m13.787s With the functions moved ahead of func_mode_compile: real24m34.235s user6m30.590s sys 11m23.878s Yes, but there is a significant speedup in real time!? That makes little sense, unless the system was busy doing other things also, for the first run. Well, yeah -- it's windows. Who KNOWS what it is doing behind the scenes. Also, I was taking the time to compose all those other emails on the same machine; I've got two cores and was only running make -j1, but I'm not surprised there was some impact on the 'real' numbers. But that should not have affected the user and sys numbers. 5% sucks a bit, fixing that should be a TODO item. It's closer to 3%: user: 6:24 = 384; 6 seconds = 1.5% sys: 11:13 = 673; 10 seconds = 1.5% Not great, and it would be nice to fix -- but not terrible. Also, I expect the impact on REAL operating systems would be less; I seem to recall that along with fork() performance, cygwin is really bad (slow) at parsing shell scripts. If we can do the magic m4 func_to_host guts-replacement, instead of using the indirection variables, that should help. But that is a longer term project. -- Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Hi Charles, * Charles Wilson wrote on Sat, Aug 28, 2010 at 07:10:25AM CEST: On 8/27/2010 3:47 PM, Ralf Wildenhues wrote: * Charles Wilson wrote on Fri, Aug 27, 2010 at 08:49:24PM CEST: However, once I have finished the requested changes above and the rebasing (plus whatever comes of the four open ***QQQ***uestions), I might ask for a 12 hour halt on updates to master so I can run those tests, if that's ok? Why should you need the halt? If there are new pushs in the meantime, you just merge origin/master into your master, and push. Doesn't that mess up the linear history of commits in the upstream master? Well, yes, if you want to call it messing up, that is. From git's perspective, origin/master and master are not the same branch in your repository. Just that most of the time, you use fast-forward or rebase when getting the changes from the former into the latter. After the push, we want master to look like this, right: + master (head): chuck's lastest commit + the next most recent commit + older commits + ... Several projects seem to require it for some notion of cleanliness, but no, if there is a good reason against that, we don't necessarily want that. Your having tested a particular commit is such a good reason, IMVHO. Not this: + master (head): merge from chuck's local master + more recent master commit + some other master commit +++ (chuck's local master): chuck's latest commit + master commit just before chuck began his final testing + older commits The text in the merge is slightly different: master: merge origin/master recent master commit .. chuck's latest commit master commit just before chuck began his final testing Or am I confused about how git handles a merge on a single (tracking) branch? No, you aren't. Just that I think that's a perfectly acceptable thing in this situation. Cheers, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Hi,
[Full quoting since I added libtool-patc...@]
Den 2010-08-25 22:28 skrev Charles Wilson:
[Added Peter]
On 8/25/2010 4:17 PM, Ralf Wildenhues wrote:
* Charles Wilson wrote on Wed, Aug 25, 2010 at 10:15:55PM CEST:
On 8/25/2010 3:50 PM, Ralf Wildenhues wrote:
just to let you know that I am working on reviewing your patch.
But it is not quick to digest ...
I know, it is a beast. Fortunately, it has been picked apart in the
past, so if you go back and review the threads I posted (which,
itself, will take some time to do) that may help make the actual
review of the current iteration a little less arduous.
I knew it would be a bear, which is why I didn't want to drop it on
everybody while we were still discussing the sysroot stuff.
Unfortunately, with the 2.2.next deadline approaching, and the
sysroot stuff still unmerged...I was running out of time. Since I
didn't want to hold Peter's MSVC stuff up any longer, AND I know
I'll need a follow-on docu patch or two...I went ahead this week.
Sorry :-(
No problem at all, that's what I get from postponing forever. Do you
know how many other non-doc patches are pending from you and Peter?
I have no idea how many patches Peter has still pending. In my queue
there are only a few -- none of which are critical for 2.2.next.
Two have already been presented, but with objections:
1) passing -{static|shared}-{libgcc|libstdc++|...} flags thru libtool
to the compiler
2) handling of win32 manifest files
In both cases, a long discussion was spawned which never reached a
conclusion about what the right thing to do is. So, I'd just punt on
both until after the next release. I'll just forward port my existing
patches, and package custom cygwin|mingw releases as I've been doing
for the last few years.
For #1, I suspect TRTTD is a big scary change: for g++ (and probably,
other gcc language drivers), don't use ld to link, and don't save
pre/post deps. Instead, for GNU tools, use the language drivers
to link. Then, there's no problem allowing these flags thru. (The
issue is, if you configure libtool *without* the flag, but use it
*with* the flag -- or vice versa -- then all your pre/post deps are
wrong.)
For #2, I'd prefer to wait until after Peter's MSVC stuff is
completely merged, and then see if the GNU toolchains for win32 can
piggy back off of any of his machinery.
Other than that, there are the following (not yet written) patches:
3) docu for this patch
4) tests for my earlier monster patch merged a few months ago (allow
-dlpreopen with -disable-shared, mostly concerned with getting the
correct symbol exports when -{enable|disable}-{static|shared}).
This is my current queue of libtool patches. They need more work.
In particular, I don't know if 0008-Slashify-instead-of-backslashify
is even remotely acceptable. The subject has been up before and I
think Chuck had some issue with it, but don't remember what. I Can do
some searching in my mailbox if that's important...
Further, my patches regresses library searching, I think due to paths
being converted from posix form to win32 form too early and then
something fails to find dependent libraries. Possibly other problems
too?
Perhaps most interesting are the patches
0002-Add-path-conversion-from-build-to-toolchain
0005-Convert-file-names-to-toolchain-format-in-NM-and-AR
which *should* fix stresstest.at on MSYS (not confirmed, due to the above
problems).
Maybe 0001-Move-path-conversion-functions-earlier-in-the-libtoo
is needed for 0002 to apply cleanly, but it should not be needed
in principle.
Anyway, here they are, just so that you can see where I'm at...
Cheers,
Peter
From c8344d25b28d300bf14124ed0fe36346a462a0f8 Mon Sep 17 00:00:00 2001
From: Peter Rosin p...@lysator.liu.se
Date: Wed, 25 Aug 2010 08:55:01 +0200
Subject: [PATCH 1/7] Move path conversion functions earlier in the libtool
script.
* libltdl/config/ltmain.m4sh (func_wine_to_win32_path)
(func_cygpath, func_msys_to_win32, func_path_convert_check)
(func_to_host_path, func_noop_path_convert)
(func_msys_to_mingw_path_convert)
(func_cygwin_to_mingw_path_convert)
(func_nix_to_mingw_path_convert)
(func_msys_to_cygwin_path_convert)
(func_nix_to_cygwin_path_convert): Move to before
func_mode_compile to make them usable from there.
Signed-off-by: Peter Rosin p...@lysator.liu.se
---
ChangeLog | 13 +
libltdl/config/ltmain.m4sh | 560 ++--
2 files changed, 295 insertions(+), 278 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index 4f11204..cda261e 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,16 @@
+2010-08-25 Peter Rosin p...@lysator.liu.se
+
+ Move path conversion functions earlier in the libtool script.
+ * libltdl/config/ltmain.m4sh (func_wine_to_win32_path)
+ (func_cygpath, func_msys_to_win32, func_path_convert_check)
+ (func_to_host_path, func_noop_path_convert)
+
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
Then, please just move the new functions where Peter needs them,
if they really need moving, that is.
I deliberately placed them after func_compile and before func_link, for
speed-of-parsing reasons. Obviously libtool is used to compile object
code much more often than it is used to link (since every linked result
requires one or more, sometimes many more, objects) -- so moving these
functions ahead of func_compile will impact speed. How much? Don't
know; I'll try to generate some numbers.
OTOH, it is absolutely *required* to move them where Peter wants them,
since he /must/ use translate some paths if func_compile is to work,
with MSVC. So...we have to pay the price regardless.
Also: I've said this before, but we can't use the m4 function_replace
magic because we need to retain the ability for users to override the
choice of $func_to_host_path_cmd. This is critical for the
'cygwin-mingw (lie)' use case, which is VERY common for the gcc developers.
Then, since the next few days might see a number of commits: in case
your redone patch does not apply or rebase cleanly against master any
more, you can easily leave that rebasing work to me, or better, just
apply it to the tree you tested against and let's merge that from
master (again, I can do that for you).
No worries. I have no issues with rebasing...but I don't plan on redoing
a week's worth of test suite runs afterward. Maybe a day's worth... :-)
* Charles Wilson wrote on Mon, Jul 19, 2010 at 03:07:01AM CEST:
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New
function sets libtool variable $to_host_path_cmd, and employs
cache. AC_SUBSTs $to_host_path_cmd, as well.
(_LT_SETUP): Require it.
* tests/testsuite.at: Ensure to_host_path_cmd is passed as a
variable setting on the configure line for (new testsuite) tests.
* Makefile.am: Ensure to_host_path_cmd is included in
TEST_ENVIRONMENT so that it is passed to (old testsuite) tests.
Typo TESTS_ENVIRONMENT.
Ack.
* libltdl/config/ltmain.m4sh (func_cygpath): New function.
(func_init_to_host_pathlist_cmd): New function.
(func_to_host_path): Refactored to... (now uses eval
$to_host_path_cmd).
(func_wine_to_win32_path): Here. New function.
(func_msys_to_win32): Here. New function.
(func_path_convert_check): Here. New function.
(func_noop_path_convert): Here. New function.
(func_msys_to_mingw_path_convert): Here. New function.
(func_cygwin_to_mingw_path_convert): Here. New function.
(func_nix_to_mingw_path_convert): Here. New function.
(func_msys_to_cygwin_path_convert): New function.
(func_nix_to_cygwin_path_convert): New function.
(func_to_host_pathlist): Refactored to... (now uses eval
$to_host_pathlist_cmd and func_init_to_host_pathlist_cmd).
(func_pathlist_convert_check): Here. New function.
(func_pathlist_front_back_pathsep): Here. New function.
(func_wine_to_win32_pathlist): Here. New function.
(func_noop_pathlist_convert): Here. New function.
(func_msys_to_mingw_pathlist_convert): Here. New function.
(func_cygwin_to_mingw_pathlist_convert): Here. New function.
(func_nix_to_mingw_pathlist_convert): Here. New function.
(func_msys_to_cygwin_pathlist_convert): New function.
(func_nix_to_cygwin_pathlist_convert): New function.
I'm not sure I've asked before, but will state again: coding up X-to-Y
for N choices of X and M choices of Y has complexity N*M, while coding
it up as from-X and to-Y has complexity N+M. Quadratic algorithms don't
scale. Why is the latter not done?
I don't think it has come up explicitly, but it also occurred
independently to me. The main issue is you don't know what the native
(e.g. central) path-type is; e.g. from-X (to what?) and (from
what?) to-Y.
Right now there are only four platforms involved: *nix, mingw, msys,
and cgywin. That's actually the break-even point, given the vagaries
and optimizations involved in these particular four platforms.
We have exactly five basic _convert functions (not counting the
_pathlist_convert extensions).
For a from-X|to-Y solution, we'd need, I think, the same number of
_convert functions: brute force suggests nine (four to_*, four from_*,
plus the noop), but then many of the from_* and to_* would actually BE noop.
I'm assuming here that the central path-type is implicitly some sort
of unixish -- maybe cyg, maybe msys, maybe unix -- path-type. The issue
is that each of the five conversion functions use a different TOOL to
perform the conversion, with different syntax. So, trying to combine, e.g.
msys_to_mingw
cygwin_to_mingw
unix_to_mingw
into an all-encompassing central_unixish_to_mingw would require
additional m4 magic to basically replace the guts depending on whether
$build was msys, cygwin, or unix. (And you can't really do a set of
{msys|cygwin|unix}_to_central_unixish that isn't simply a no-op --
because (A) they already are all unixish, and (B) what tool would you
use? How would the later to_mingw function
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 8/26/2010 6:27 PM, Roumen Petrov wrote: Starting from wine 1.3.1 wine path always output paths: Lets wine is correctly configured (Z: drive is linked to the file system root): $ cd $WINEPREFIX/dosdevices $ winepath -w `pwd` Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices Now lets remove link: $ rm z: $ winepath -w `pwd` \\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices So sed should remove leading //?/unix I can't test this. The wine-1.3.x series is the development series, and none of the linux distributors include it in their offerings (you're lucky to get 1.2). For the initial submission, I'm not willing to make changes I can't test. After the first round is merged, feel free to propose a change that you've tested on both wine-1.2 and wine-1.3.x. Thanks, Chuck
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Ralf Wildenhues wrote:
Hi Charles,
[SNIP]
+ func_wine_to_win32_path_result=$1
+ if test -n $1; then
+# 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:
Starting from wine 1.3.1 wine path always output paths:
Lets wine is correctly configured (Z: drive is linked to the file system
root):
$ cd $WINEPREFIX/dosdevices
$ winepath -w `pwd`
Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
Now lets remove link:
$ rm z:
$ winepath -w `pwd`
\\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
So sed should remove leading //?/unix
Peter, are you reading this? Looks like a TODO item for
automake/lib/compile. ;-)
+func_wine_to_win32_path_tmp=`winepath -w $1 2/dev/null`
+if test $? -eq 0 test -n ${func_wine_to_win32_path_tmp}; then
I'll just note that some shells ((d?)ash 0.2) fail to propagate the exit
status of an assignment. No need to change the code, but users should
have a decent shell for this.
+ func_wine_to_win32_path_result=`$ECHO $func_wine_to_win32_path_tmp |
+$SED -e $lt_sed_naive_backslashify`
+else
+ func_wine_to_win32_path_result=
The way this is coded, correctness relies on the fact that all code
paths that invoke this function do eventually check for non-emptiness
of the result.
+fi
+ fi
+}
+# end: func_wine_to_win32_path
[SNIP]
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* Charles Wilson wrote on Thu, Aug 26, 2010 at 11:20:48PM CEST: Also: I've said this before, but we can't use the m4 function_replace magic because we need to retain the ability for users to override the choice of $func_to_host_path_cmd. This is critical for the 'cygwin-mingw (lie)' use case, which is VERY common for the gcc developers. Do you need an override at 'make' time or does one at configure time suffice? Because if the latter (which I'm assuming), then from my POV the above is just a statement that function_replace is not good enough for your needs, not one it cannot be done. Please don't get into the habit of saying that something cannot be done if there's just another TODO item which you (understandably) may not want to fix yourself. That is very confusing in a technical discussion. Thanks. On 8/26/2010 4:18 PM, Ralf Wildenhues wrote: I'm not sure I've asked before, but will state again: coding up X-to-Y for N choices of X and M choices of Y has complexity N*M, while coding it up as from-X and to-Y has complexity N+M. Quadratic algorithms don't scale. Why is the latter not done? I don't think it has come up explicitly, but it also occurred independently to me. The main issue is you don't know what the native (e.g. central) path-type is; e.g. from-X (to what?) and (from what?) to-Y. Right. [...] So...I don't think it makes much difference *right now* in the amount of code required, or the number of functions implemented. Beside looking fairly ugly, yes. OTOH, as a follow-on patch after 2.2.next, we could implement an explicit N+M scheme just so that any future extensions -- which I can't actually foresee -- could hook in scalably. Oh no, please not code which already sets out as dead code. If there is a need for more translations, then maybe, but then I'd suggest there'd be an effort to get as many of the w32 translators under the same hood as possible. The answer should be in a comment in the code, if it cannot be done. If it can be done, then I am OK with making it a TODO item to be addressed after 2.2.12, rationale being that that's just an optimization so QoI issue, whereas your patch brings new features. Err... ^^^ that's quite a long comment to parse in ltmain.m4sh...maybe a short note to see the TODO file, and put the bulk there? Sure; just a TODO file entry seems fine, too. Point is that it's not just in mail. Cheers, Ralf
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
Den 2010-07-19 03:07 skrev Charles Wilson:
*snip*
Congratulations, you have reached the end of this message, and can
now review the 750 line patch!
I did wonder when I was going to get some meat :-)
*snip*
+func_wine_to_win32_pathlist ()
+{
+ $opt_debug
+ # unfortunately, winepath doesn't convert pathlists
But you can feed it multiple things to do in one go though if
I understand correctly:
winepath /first/filename /second/filename ...
I don't know how the output is formated though (one file per line
probably). And besides, you're just shuffling code around so not
an issue for this patch...
*snip*
+ fi
+}
+# end func_nix_to_cygwin_pathlist_convert
+
git am printed the warning below about the above hunk:
warning: 1 line adds whitespace errors.
I have rebased those of my old patches that are still applicable,
and will run some tests with MSYS/gcc, MSYS/MSVC and Cygwin/MSVC
to check which failures have been fixed. What? Regressions? No way,
I don't want those! :-)
I'll report back with the results (and perhaps the patches)...
Cheers,
Peter
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 7/18/2010 9:07 PM, Charles Wilson wrote: stuff Sorry about the date. Blame 'git format-patch'. -- Chuck
[PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function sets libtool variable $to_host_path_cmd, and employs cache. AC_SUBSTs $to_host_path_cmd, as well. (_LT_SETUP): Require it. * tests/testsuite.at: Ensure to_host_path_cmd is passed as a variable setting on the configure line for (new testsuite) tests. * Makefile.am: Ensure to_host_path_cmd is included in TEST_ENVIRONMENT so that it is passed to (old testsuite) tests. * libltdl/config/ltmain.m4sh (func_cygpath): New function. (func_init_to_host_pathlist_cmd): New function. (func_to_host_path): Refactored to... (now uses eval $to_host_path_cmd). (func_wine_to_win32_path): Here. New function. (func_msys_to_win32): Here. New function. (func_path_convert_check): Here. New function. (func_noop_path_convert): Here. New function. (func_msys_to_mingw_path_convert): Here. New function. (func_cygwin_to_mingw_path_convert): Here. New function. (func_nix_to_mingw_path_convert): Here. New function. (func_msys_to_cygwin_path_convert): New function. (func_nix_to_cygwin_path_convert): New function. (func_to_host_pathlist): Refactored to... (now uses eval $to_host_pathlist_cmd and func_init_to_host_pathlist_cmd). (func_pathlist_convert_check): Here. New function. (func_pathlist_front_back_pathsep): Here. New function. (func_wine_to_win32_pathlist): Here. New function. (func_noop_pathlist_convert): Here. New function. (func_msys_to_mingw_pathlist_convert): Here. New function. (func_cygwin_to_mingw_pathlist_convert): Here. New function. (func_nix_to_mingw_pathlist_convert): Here. New function. (func_msys_to_cygwin_pathlist_convert): New function. (func_nix_to_cygwin_pathlist_convert): New function. --- Originally posted here: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg6.html but much changed since then. This version actually resembles closely version 5, below -- and the link there includes a good summary discussion particularly intended for those who had forgotten all the context and previous discussion concerning this patch, over the intervening 6 months. Since it's now been 14 months later...it's still a good review. So go read it. See also http://www.cygwin.com/ml/cygwin/2009-02/msg00555.html but ignore the rest of the thread; there was not a single on-topic reply and nobody responded to my call for test. :-( version 2: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html version 3: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html version 3a (an overlay on version 3) http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html More disucssion here: http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00010.html version 4 (squashed 3 and 3a): http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00012.html version 5 (ignore the bogus changelog and the first URL in this message): http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00030.html but the other two URLs in that message are relevant and accurate). Interesting background discussion here: http://cygwin.com/ml/cygwin/2009-01/msg00808.html The original motivation was to enable correct cwrapper *execution* when cross-compiling to a cygwin target (from linux, primarily) -- where the $build machine was (a) x86 (b) and had wine (c) and had a cygwin installation that could be executed under wine. However, the framework is, I think, useful for other situations -- and it is a strict improvement for unix-mingw and cygwin-mingw cross compilation, IMO, because it (a) cleans up and refactors the existing hodgepodge of case statements for path translation, by (b) moving a lot of that over to libtool.m4, and (c) uses cacheable -- and thus overridable -- indirection vars to invoke the correct refactored path translation function (this override capability is needed for the lie to me use case; see cygwin-mingw (lie) below). That's good, because in the interim between Jan 2009 and now, things outside of libtool's control have changed: Running cygwin under wine has always been...complicated, but at least in the relatively recent past simple .exe's and especially cygpath.exe could be executed without issue. As of cygwin-1.7, that no longer appears to be true; I can only occassionally get any cygwin application to execute under wine without coredumping -- including cygpath. This might be PIBKAC, since I have updated/reinstalled my linux OS two or three times since then; OTOH others have reported difficulties with cygwin-1.7 on wine, too. Fortunately, the default behavior implemented by this patch (for *nix-cygwin cross) relies on the value of the user-set variable LT_CYGPATH (whose value is, obviously, by default empty). In that case, the path-conversion logic for unix-cygwin halts after the interim unix-dos conversion, complains about the empty LT_CYGPATH value, and continues without error. The result of this is simply the status quo: the wrapper exe won't work correctly, and you won't be able to launch
Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)
On 7/18/2010 9:07 PM, Charles Wilson wrote: cygwin-mingw cross (faked) cygwin-mingw cross (lie) to follow in a later message. linux-mingw cross == linux-mingw (old tests): 2 of 100 FAIL, 6 SKIP FAIL: tests/demo-hardcode.test FAIL: tests/depdemo-relink.test Don't know if these are regressions or not; will recheck without this patch. Not regressions; I get the same results without this patch. linux-cygwin cross (LT_CYGPATH not set) === linux-cygwin (old tests): 1 of 114 FAIL, 10 SKIP FAIL: tests/demo-hardcode.test Ditto: don't know if this is a regression or not; will recheck without this patch. Not a regression; same results without this patch. linux-cygwin (new tests): AWFUL. 23 unexpected failures 32 skip I don't expect any difference WITH LT_CYGPATH set, because cygpath-1.7 (and, indeed, all cygwin-1.7 programs) seems to crash under wine anyway. I need to investigate this and re-run in this configuration without this patch, to verify that these failures are not regressions. I don't *think* the changes in this patch could have caused them... Also not regressions. In fact, the unmodified version is actually even worse; it fails the following tests which the patched version does not (the patched version skips all three): 39: Link order of deplibs FAILED (link-order2.at:125) 100: template test with subdirs FAILED (template.at:243) 101: C++ static constructors FAILED (ctor.at:65) I'm not sure what's going on here, but it obviously is not a problem with this patch. I suspect my cygwin cross compiler may actually be broken; it's a brand new build, and I've never done a linux-cygwin compiler before...it's possible I messed something up: i686-pc-cygwin-gcc can compile hello_world.c and the result works ok when copied back to the windows machine. However, i686-pc-cygwin-g++ is not so lucky; hello_world.cpp's exe coredumps on win32 if used with the cygwin-provided cygstdc++-6.dll. When used with the cygstdc++-6.dll built as part of the cross toolchain, it doesn't coredump -- but doesn't print anything to stdout either. So...I'm thinking my cygwin cross compiler is borked. I'll look in to the issue...but I don't think it should hold up this patch. You might think it odd that I created this patch, originally, to assist the linux-cygwin scenario, when I didn't actually have or use a toolchain of that type. Well, that's true: I tested everything involved in the nix-cygwin path of this patch (path conversion sh functions, etc) as much as I could in vitro, but never could test that part in vivo. I kept hoping SOMEBODY on the cygwin list would respond to my Call For Testing, but no such luck. Therefore, I finally attempted to create my own linux-cygwin toolchain, but...it's early days yet for that. -- Chuck
