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
[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 t
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
Re: [PATCH] Fix syntax for cygwin-cross
On 8/23/2010 1:34 AM, Ralf Wildenhues wrote: * Charles Wilson wrote on Mon, Aug 23, 2010 at 07:18:18AM CEST: libltdl/m4/argz.m4: Add quotes around variable, which may contain the multiword value 'guessing no'. OK, thanks! Oops. Forgot to say: "pushed". This should probably also go upstream to gnulib. Yes, will sync there later. ...and ack that Eric Blake already did this. -- Chuck
Re: [PATCH] Allow the use of a listing file if the archiver supports it.
Hi Peter, * Peter Rosin wrote on Tue, Aug 24, 2010 at 11:48:50AM CEST: > Hmmm, your cross-post on bug-libtool@ and gcc@ made me look > one more time at this, and I realized that I have previously > completely misunderstood the failure. There isn't any piecewise > linking ($CC -r -o) going on in the other fallback code branch > (as is the case for the fallback for the name lister). Correct. > The old ar fallback is simply adding objects to the archive in batches > when the command line gets longish... Right. > Thanks to the ar-lib script, it's no longer a special action > to add members to an archive using Microsoft lib, i.e. the old > fallback *should* work (I haven't tested for real, but I have > tested that ar-lib can add objects to an existing archive). Great! > So in case there are GCC problems with this patch (it was this > change you referred to in that post, right?), it's perfectly > fine with me to revert it. Yes, it was this change I referred to, but no, there do not seem to be problems with the patch. It doesn't need reversal. In fact, the @file mechanism gets used with newish binutils on GNU/Linux as well and I'm happy with that. :-) (For reference, the situation I was thinking of was newly-built ar in a combined GCC+src/binutils build, possibly including cross compilation.) > An added benefit of reverting would be that absolute file names > starts working for MSYS again (both MinGW and MSVC) without > Chuck's pending patches. Hmm. I wasn't aware that it was that which caused it to regress. > Another benefit of reverting is that if the objects are passed > on the command line, libtool isn't forced to convert absolute > file names it adds to the @file (on MSYS, still needed for > Cygwin), and we have learned that that can make some speed > difference... > > On the other hand, the patch should be a (minor) speed > improvement in the normal case of relative file names. Right. At this point, I think it's best to defer to Chuck's and your good judgement on what you consider better for w32. If Chuck's pending patches are planned before the release, then hey, let's go forward with them if you agree. Thanks, Ralf
Re: [PATCH] Allow the use of a listing file if the archiver supports it.
Den 2010-08-13 13:17 skrev Peter Rosin: > Den 2010-08-12 19:49 skrev Ralf Wildenhues: >> Hi Peter, >> >> * Peter Rosin wrote on Thu, Aug 12, 2010 at 03:28:57PM CEST: >>> This is a patch that makes use of @FILE support in the >>> archiver, if the archiver supports it. That makes linking >>> succeed for long command lines when using MSVC, as MSVC >>> can't do piecewise linking (-r -o) which is the current >>> fallback. Absolute paths still needs work, but that will >>> have to wait for Chucks work in that area. >> >> Absolute paths are not a show stopper, for practical purposes. >> >> This is ok for master with nits below addressed. > > Thanks for the review! *snip* > I have pushed as attached. *snip* Hmmm, your cross-post on bug-libtool@ and gcc@ made me look one more time at this, and I realized that I have previously completely misunderstood the failure. There isn't any piecewise linking ($CC -r -o) going on in the other fallback code branch (as is the case for the fallback for the name lister). The old ar fallback is simply adding objects to the archive in batches when the command line gets longish... Thanks to the ar-lib script, it's no longer a special action to add members to an archive using Microsoft lib, i.e. the old fallback *should* work (I haven't tested for real, but I have tested that ar-lib can add objects to an existing archive). So in case there are GCC problems with this patch (it was this change you referred to in that post, right?), it's perfectly fine with me to revert it. An added benefit of reverting would be that absolute file names starts working for MSYS again (both MinGW and MSVC) without Chuck's pending patches. Another benefit of reverting is that if the objects are passed on the command line, libtool isn't forced to convert absolute file names it adds to the @file (on MSYS, still needed for Cygwin), and we have learned that that can make some speed difference... On the other hand, the patch should be a (minor) speed improvement in the normal case of relative file names. Cheers, Peter
