Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Charles Wilson wrote: In fact, maybe I should add $opt_debug to the new func_to_host_path[list] functions... Addressed in the attached revision. cygwin-native testsuite behavior is as expected.q still true. mingw-native (e.g. msys-mingw) testsuite behavior is as expected. still true. cygwin-mingw testsuite behavior didn't really work, but it does not appear to be as a result of this patch. [*] I think we've more-or-less reached a consensus that cygwin-mingw cross should be treated, by default, as a cygwin to mingw cross (fancy that!) -- in that the compiler should be considered a normal cross-compiler running under cygwin with the ability to understand cygwin paths, symlinks, etc, which happens to generate mingw code. But also, that many people DO use cygwin to drive a native mingw compile process (not MSYS), when building gcc/binutils or other libraries and applications. http://cygwin.com/ml/cygwin/2009-01/msg00808.html (LONG thread). The most prominent example, is that several prominent folks use cygwin to bootstrap native mingw gcc toolchains, by lying: (1) configure --build=mingw32 --host=mingw32 --target=mingw32, which currently works. However, Danny reports that (2) configure --build=cygwin --host=mingw32 --target=mingw32 ALSO currently works. This tells us two things: From scenario (2)... Because the compilers built during this process will all be native, they don't understand the cygwin paths nor symlinks. However, because (2) works anyway, this means that gcc, at least, is structured in such a way that the bootstrap process does not use symlinks nor absolute paths, when building for mingw $host and $target -- even though $build in this case supports it. This is not surprising; how else could --build=linux --host=mingw32 --target=mingw32 work? Of course, since $build != $host, in this case a full triple bootstrap is not performed -- and the testsuite is not run by default (unknown if Danny tries to manually run the testsuite in this configuration). From scenario (1)... Given that current gcc includes a fairly recent libtool with an early version of the func_to_host_path stuff, then IF gcc actually /used/ that libtool to build executables requiring wrapper exes, THEN those executables would be broken -- because even the old func_to_host_path stuff would (a) think that $build=mingw (e.g. msys) because that's what you told it (b) know that $host=mingw (c) use the `( cmd //c echo $1 ) ...` construction to convert the paths. (d) This will fail when the ACTUAL $build is cygwin. However, because Danny says (1) works, currently, this implies that gcc, at least, never uses libtool to build executables -- utilities, or test programs. Therefore, the (1) scenario of (triple) bootstrapping mingw gcc under cygwin (by claiming $build=mingw) should continue to work, even with this patch. That, to me, is a great relief. Now, this doesn't address any possible (probable?) issues with lying to configure about $build for OTHER packages. The attached update attempts to provide end-users with the capability -- although esoteric -- to address them. Basically, I made the to_host_path[list]_cmd variables cached, so that you COULD do this: $ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert $ export lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert $ configure --build=mingw32 --host-mingw32 (--target=ming32, if building a tool chain package like binutils or gcc; but apparently this lt_cv* workaround is not necessary for building gcc, yay!) and libtool will NOT use the func_msys_to_mingw_path_convert functions as it normally would for this build/host/target, but instead will use the correct cygwin_to_mingw ones. Coupled with some of Peter's patches to use the (generic encapsulation functions) func_to_host_path[list](), this will address many, if not all, of the issues that may arise (and probably already DO arise, with ToT libtool, for any package OTHER than gcc!) with this scenario. I'd like for somebody to verify that I haven't broken unix-mingw I think Roumen Petrov has verified this; but I can't find the message in the archives. Also, if somebody could verify that the new unix-cygwin support works (ditto lt-demo.c), that'd be great. Nobody has chimed in here, but I'll use a 'test release' over on cygwin-apps to get wider testing. But I'd really rather not wait on that to get the rest of these changes in...can this patch be accepted without explicitly testing the one new facility also included in it? [*] I had to configure as follows: $ export PATH=/c/MinGW/bin:$PATH $ ../libtool/configure --build=i686-pc-cygwin --host=mingw32 NM=/c/MinGW/bin/nm.exe [snip various problems that occur in this configuration] I believe most of these issues are addressed by Peter's patches, which use the (generic encapsulation functions) func_to_host_path[list](). And, perhaps, by --disable-dependency-tracking (since cygwin-make does not grok the dependency
Re: [PATCH] Document and test LT_DEBUGWRAPPER cwrapper macro
Charles Wilson wrote: * tests/cwrapper.test: Add new test for -DLT_DEBUGWRAPPER. * doc/libtool.texi [Linking executables]: Mention wrapper executables, in addition to wrapper scripts. Add menu referencing subsection 'Wrapper executables for programs'. [Wrapper executables for programs]: New subsection. Documents cwrapper rationale, command line options, and LT_DEBUGWRAPPER macro. --- OK to push? For once, it's a nice, simple, small patch g. Ping? FWIW, I plan to expand on the [Wrapper executables for programs] documentation after (assuming) the cross-compile stuff goes in. Some of that info will be taken from here: http://cygwin.com/ml/cygwin/2009-01/msg00851.html The interesting bits start with But I worry that things, although there is one misconception; at the time I thought that current gcc used old libtool (2007-03-18). It doesn't -- it uses 2009-09-26). However, the description of why we use a wrapper exe, and why we eliminated the wrapper script entirely, and why *WE* have to worry about converting paths manually from one format to another are all good. -- Chuck
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Den 2009-01-30 19:28, skrev Charles Wilson: I think we've more-or-less reached a consensus that cygwin-mingw cross should be treated, by default, as a cygwin to mingw cross (fancy that!) -- in that the compiler should be considered a normal cross-compiler running under cygwin with the ability to understand cygwin paths, symlinks, etc, which happens to generate mingw code. But also, that many people DO use cygwin to drive a native mingw compile process (not MSYS), when building gcc/binutils or other libraries and applications. http://cygwin.com/ml/cygwin/2009-01/msg00808.html (LONG thread). The most prominent example, is that several prominent folks use cygwin to bootstrap native mingw gcc toolchains, by lying: (1) configure --build=mingw32 --host=mingw32 --target=mingw32, which currently works. However, Danny reports that (2) configure --build=cygwin --host=mingw32 --target=mingw32 ALSO currently works. This tells us two things: From scenario (2)... Because the compilers built during this process will all be native, they don't understand the cygwin paths nor symlinks. However, because (2) works anyway, this means that gcc, at least, is structured in such a way that the bootstrap process does not use symlinks nor absolute paths, when building for mingw $host and $target -- even though $build in this case supports it. This is not surprising; how else could --build=linux --host=mingw32 --target=mingw32 work? Of course, since $build != $host, in this case a full triple bootstrap is not performed -- and the testsuite is not run by default (unknown if Danny tries to manually run the testsuite in this configuration). From scenario (1)... Given that current gcc includes a fairly recent libtool with an early version of the func_to_host_path stuff, then IF gcc actually /used/ that libtool to build executables requiring wrapper exes, THEN those executables would be broken -- because even the old func_to_host_path stuff would (a) think that $build=mingw (e.g. msys) because that's what you told it (b) know that $host=mingw (c) use the `( cmd //c echo $1 ) ...` construction to convert the paths. (d) This will fail when the ACTUAL $build is cygwin. However, because Danny says (1) works, currently, this implies that gcc, at least, never uses libtool to build executables -- utilities, or test programs. Therefore, the (1) scenario of (triple) bootstrapping mingw gcc under cygwin (by claiming $build=mingw) should continue to work, even with this patch. That, to me, is a great relief. Now, this doesn't address any possible (probable?) issues with lying to configure about $build for OTHER packages. The attached update attempts to provide end-users with the capability -- although esoteric -- to address them. Basically, I made the to_host_path[list]_cmd variables cached, so that you COULD do this: $ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert $ export lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert $ configure --build=mingw32 --host-mingw32 (--target=ming32, if building a tool chain package like binutils or gcc; but apparently this lt_cv* workaround is not necessary for building gcc, yay!) and libtool will NOT use the func_msys_to_mingw_path_convert functions as it normally would for this build/host/target, but instead will use the correct cygwin_to_mingw ones. Coupled with some of Peter's patches to use the (generic encapsulation functions) func_to_host_path[list](), this will address many, if not all, of the issues that may arise (and probably already DO arise, with ToT libtool, for any package OTHER than gcc!) with this scenario. *snip* So, the attached patch represents the third revision. The change history is the same the one for version #2 at: http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html The implementation differences from version #2 are: (1) to_host_path[list]_cmd are now cached variables (2) all of the new functions use $opt_debug Note that many of Peter's pr-msvc-branch fixes depend on this patch, so we have a bit of a chicken/egg problem with regards to TAG, above. It's been cooking in my head for a couple of days now, and I think it's time to throw out the old response I was writing and start over... There are two new scenarios that I see (in addition to normal native builds and normal crosses). (1) $host=$build, but scripts are not running on $build (lying) (2) $host!=$build, but we are able the execute $host code. Your patch is about making the cwrapper work. However, in order to fully support (1), more changes are needed. E.g. When you feed paths to the linker in a command file, MSYS does not get to see those files, so you have to make the conversion manually. This conversion will be the same as the one needed for cwrapper but still different. However, the older MSVC support had a similar concept in the fix_srcfile_path, but that is very limited in scope compared to this patch. Further down the road (as evident
