[PATCH] [cygwin]: Add cross-compile support to cwrapper take 5
really ought to mean the same thing that any other --build=A --host=B configuration does: a CROSS environment, where the $build tools (compiler, but ALSO OS utilities like ln, uname, expr, cat) are true entities in the $build environment. For instance, if --build=cygiwn, then cat understands cygwin (that is, unix) paths and does not grok win32 (C:/foo) paths. Ditto -- most especially ditto -- for gcc: it's a program running on $build that makes $host output, and therefore gcc expects $build-style input paths. This is NOT the case if the gcc you are using is actually the MinGW- supplied gcc.exe. So, as a special workaround for those people who a) insist on lying to configure and claim that --build=mingw when it is actually cygwin b) are building/compiling a package that actually needs to use the cwrappers (that is, not binutils nor gcc) then what they need to do is the following: $ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert $ configure --build=mingw32 --host=mingw32 [--target=mingw32 [*]] [*] Note that only toolchain packages (like binutils or gcc) ever need to be given a --target specification. However, since as described above, gcc/binutils luckily don't need to worry about this cwrapper issue, in practice you'd never need to override lt_cv_to_host_path* AND invoke configure with all three --build/--host/--target. (It's actually not luck. This is a consequence of the gcc/binutils folks taking special care for the mingw compilers in cross- and canadian-cross- scenarios. They already had to ensure that symlinks were never used in the tree, because otherwise the just-built gcc wouldn't be able to build its runtime libraries. Other issues also dictate this serendipitous result). For more discussion of this issue, see the following: [Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper] http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html subthread [RFD: cygwin + *native* MinGW compiler] http://cygwin.com/ml/cygwin/2009-01/msg00808.html thread [***] assuming you have WINE installed, and the winepath executable can be found in the $PATH on $build, and the linux-only binfmt kernel extension is enabled. [] This is a regression in libtool-master ToT. With libtool-1.5.x, this used to work under the same circumstances as [***], but with current libtool-master and all libtool-2.2.x, it does not. So, just as unix - mingw cross builds need special support when creating the cwrapper source code in order for the cwrapper to work properly under the wine environment, so too do unix - cygwin cross builds. However, this led to a lot of duplicated code, so I refactored a bit. WITH this patch, all of the OK items above remain OK (I've tested the native mingw-mingw and cygwin-cygwin, and long ago Roumen Petrov tested the unix/WINE-mingw case with this patch; Peter Rosen tested the MSYS/msvc-native case with his additional patchset) unix - cygwin *should* work, but I can't test it I'm hoping that somebody, with a working cygwin-under-WINE installation can please do so. I do know that the core logic works, because I've been able to extract that into a separate script and test it. HOWEVER: even supposing that the putative unix-cygwin support DOESN'T work (and I strongly believe it DOES work) the attached patch is still a strict improvement over current libtool-master, 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. NOTE: At present, to use the unix - cygwin support, you *MUST* have the LT_CYGPATH environment variable exported, containing the *unix* (that is, $build) path to the cygpath.exe you want to use. # The full *nix (or msys) path to the cygpath program must be # specified in the LT_CYGPATH environment variable. This # is because (a) the cygpath program shouldn't be in $PATH, # because it usually lives in cygwin's bin/ directory -- # along with *cygwin* versions of sed, id, cp. If the *nix (or # msys) host environment had those programs in its $PATH, many # bad things could happen. (b) especially in cygwin-1.7, multiple # installations (with separate mount tables in # CYGROOT-N/etc/fstab) can coexist on the same Win32 # instance. The cygpath.exe for cygwin installation #N in # CYGROOT-N/bin automatically deduces the appropriate # ../etc/fstab file. Therefore, it matters which cygpath.exe # is used. LT_CYGPATH may be replaced or supplemented by an # LT_INIT-activated configure option in the future. Oh: one other thing. I know using 'win32' is frowned upon
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper take 5
Charles Wilson wrote: ... a long correct message but with the wrong changelog. sorry. Here's the correct changelog. - Refactor cwrapper cross-compile support; Add cygwin. * 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.
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Charles Wilson wrote:
Charles Wilson wrote:
How does that sound, as an intermediate plan?
Implemented as attached, which should be applied on top of the -take3 patch.
Ping?
The attached represents the combination of -take3
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html
ChangeLog for that piece is here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html
And the followup *addendum* patch, with an associated pseudo-changelog:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html
These two *could* be reviewed separately, if that is preferable. Or,
just look at the attached combo patch.
ChangeLog (for combo patch)
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.
diff --git a/Makefile.am b/Makefile.am
index 574147d..9cd1628 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -507,7 +507,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)
BUILDCHECK_ENVIRONMENT = _lt_pkgdatadir=$(abs_top_srcdir) \
LIBTOOLIZE=$(abs_top_builddir)/libtoolize \
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 49e07c3..d362d73 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2533,166 +2533,595 @@ fi\
}
+
+# PATH CONVERSION HELPER FUNCTIONS #
+
+
+# func_wine_to_win32_path ARG
+# Helper function used by path conversion functions
+# when $build is *nix, and $host is mingw, cygwin,
+# or some other win32 environment. Relies on a
+# correctly configured wine environment available,
+# with the winepath program in $build's $PATH.
+#
+# 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_path ()
+{
+ $opt_debug
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ 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:
+func_to_host_path_tmp1=`winepath -w $1 2/dev/null`
+if test $? -eq 0 test -n ${func_wine_to_win32_path_tmp}; then
+ func_to_host_path_result=`$ECHO $func_wine_to_win32_path_tmp |
+$SED -e $lt_sed_naive_backslashify`
+else
+ func_wine_to_win32_path_result=
+fi
+ fi
+}
+# end: func_wine_to_win32_path
+
+
+# func_wine_to_win32_pathlist ARG
+# Helper function used by path conversion functions
+# when $build is *nix, and $host is mingw, cygwin,
+# or some other win32 environment. Relies on a
+# correctly configured wine environment available,
+# with the winepath program in $build's $PATH.
+# Assumes ARG has no leading or trailing path separator
+# characters.
+#
+# ARG is pathlist to be
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Den 2009-01-30 19:28 skrev Charles Wilson:
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.
*snip*
+func_msys_to_win32 ()
+{
+ $opt_debug
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ # awkward: cmd appends spaces to result
+ func_msys_to_win32_result=`( cmd //c echo $1 ) 2/dev/null |
+$SED -e 's/[ ]*$//' -e $lt_sed_naive_backslashify`
+}
Might I suggest
+func_msys_to_win32 ()
+{
+ $opt_debug
+ lt_sed_naive_slashify='s|\\|/|g'
+ # awkward: cmd appends spaces to result
+ func_msys_to_win32_result=`( cmd //c echo $1 ) 2/dev/null |
+$SED -e 's/[ ]*$//' -e $lt_sed_naive_slashify`
+}
instead? And perhaps a similar change to func_wine_to_win32_path, but
I have not tested that.
*snip*
After all, you are using
+func_to_host_path_result=`cygpath -m $1`
in func_cygwin_to_mingw_path_convert, so you appear to be happy with
forward slashes in other places.
The reason I'm requesting this change is that a later patch introducing
func_to_tool_path which reuses these functions will need to quote
paths for eval in some places if they might contain backslashes, and
quoting for eval will cost forks on sane setups that don't deserve to
lose.
Also, I'm curious, what is the difference between mingw and win32 in this
context, i.e. why not name the function func_cygwin_to_win32_path_convert?
Cheers,
peter
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] [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
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Den 2009-01-24 16:47 skrev Charles Wilson:
*snip*
This is a revised version of the original patch. The main difference
is that rather than one giant func_to_host_path or func_to_host_pathlist
function, all of the various host/build combinations have been split
into separate functions, and the appropriate one is used depending on
the value of the configure variables $to_host_path_cmd and
$to_host_pathlist_cmd. I considered trying something clever (like
the XSI shell functions) where only the functions needed by the
specific configuration were included in the libtool script, but
I couldn't see how to ensure they were placed at the proper location
in the libtool script. Using the same mechanism as the XSI ones would
put them WAY too early. Somehow inserting them just before func_mode_link
just doesn't seem possible without a lot of infrastructure changes --
more than I want to address in this patch.
Maybe we can look at that later.
One other possible change: The func_to_host_path() function now looks
like this:
func_to_host_path ()
{
eval '$to_host_path_cmd $1'
}
I could instead change every occurence of 'func_to_host_path $somevar'
to eval '$to_host_path_cmd $somevar' directly, but I sorta like the
indirection, because it allows possible decoration (like $opt_debug).
In fact, maybe I should add $opt_debug to the new func_to_host_path[list]
functions...
cygwin-native testsuite behavior is as expected.
mingw-native (e.g. msys-mingw) testsuite behavior is as expected.
cygwin-mingw testsuite behavior didn't really work, but it does not
appear to be as a result of this patch. [*]
I'd like for somebody to verify that I haven't broken unix-mingw (and post
one of the lt-demo.c files from one of the old tests). Also, if somebody could
verify that the new unix-cygwin support works (ditto lt-demo.c), that'd be
great.
[*] 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
because otherwise, cygwin's link.exe got selected as the name lister. I think
this
is because one (or more) of Peter's fixes has not yet been merged. Also, without
That would be this one:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00055.html
Peter's other fixes, building libltdl (preopen) requires ar to explode
loadlibrary.a,
but ar is the native mingw one while the path to loadlibrary.a is presented in
cygwin format. Finally -- there's one problem without an obvious fix: cygwin's
make no longer supports dos-style paths (in target rules, which isn't the
problem
here), nor in .deps files (which IS the problem). The .deps files are generated
by (mingw native) gcc, and therefore contain DOS-style paths.
The MSYS make supports those kind of paths, but you can't really use MSYS exes
from
a cygwin environment. Trying to use mingw32-make presents the opposite problem
in
this cross-build: it only understands DOS paths, but the Makefile rules are
in terms of cygwin (unix-like) paths. I know that Danny Smith uses
cygwin-mingw
as his primary environment to build gcc itself; I wonder what make executable
he uses...
First off, your patch works like a charm on MSYS/MSVC, and I generally
like it.
But... (skip to where I get hit with a cluebat, unless
you enjoy the writings of a, ahem, moron...)
I don't think we should try to support the scenario where the MinGW gcc,
exactly as supplied by the MinGW project, is executed from within Cygwin.
It's a lot saner to just support an ordinary Cygwin-MinGW cross instead,
just as on *nix. That way all tools expect Cygwin paths, and all tools spit
out Cygwin paths.
I.e. I don't think I want func_cygwin_to_mingw_path_convert and
func_cygwin_to_mingw_pathlist_convert to exist.
Or have I misunderstood things completely? From within Cygwin, aren't
both the current gcc -mno-cygwin and the future invocation
i686-pc-mingw32-gcc both referring to toolchains that understands
Cygwin paths, as opposed to the gcc from the MinGW project that is only
dealing with win32 paths (and knows nada about msys paths)?
On at least my Cygwin install, every .exe beneath the folder
/usr/lib/gcc/i686-pc-mingw32/3.4.4 is a symlink to the i686-pc-cygwin
area, which suggests that they at least have the potential to
grock Cygwin paths (since the i686-pc-cygwin stuff has to)...
*time passes*
*I get hit with a cluebat*
Ah, the cwrapper is compiled with the cross compiler, it's when the
cwrapper executes that it has pretty special needs!
*time passes*
But a couple of questions are open, when did native MinGW ar enter the
picture when $build = cygwin and why is there a problem with leakage
of paths from the other environment? I thought the tools when $build
is Cygwin are ordinary cross tools (albeit with a strange name so far)?
However, all that aside, is func_noop_path_convert a good idea?
Wouldn't it be better to just leave to_host_path_cmd empty in that
case and
Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper
Peter Rosin wrote:
First off, your patch works like a charm on MSYS/MSVC, and I generally
like it.
But a couple of questions are open, when did native MinGW ar enter the
picture when $build = cygwin and why is there a problem with leakage
of paths from the other environment? I thought the tools when $build
is Cygwin are ordinary cross tools (albeit with a strange name so far)?
I was deliberately testing the case where you use the MinGW native
toolchain from the cygwin environment. I had the impression that was
pretty common, because MSYS is, well, limited. Old. Slow to be updated.
Based off an ancient fork of cygwin. Not many ported utilities. Heck,
I'm not even sure it works on Vista with UAC (maybe it does). So, I
figured a lot of folks probably try to drive the official MinGW gcc
using the cygwin bash/tools rather than the MSYS bash/tools. But maybe
they all lie, like Danny does below...
[NB: see thread RFD: cygwin + *native* MinGW compiler
http://cygwin.com/ml/cygwin/2009-01/msg00808.html ]
In fact, Danny Smith [*] stated:
http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01162.html
[I use most often...]
-build=i686-pc-mingw32 --host=i686-pc-mingw32 --target=i686-pc-mingw32
[with] cygwin bash and tools
[*] ex-MinGW maintainer /of/ gcc, now currently one of the gcc
maintainers /for/ MinGW. (Trust me, the two roles sound similar but are
quite different in practice.) Point is, I don't want to break Danny's
use case!
Now, Danny's actually lying to configure, when he claims that $build ==
mingw32, when it is actually cygwin. And, without any other
considerations, his use case may break my patch (or vice versa). You'd
end up calling func_msys_to_mingw, which relies on the msys magic path
conversion logic:
( cmd //c echo $1 )
MSYS (but not cygwin) notices that cmd is a native win32 program, and
that there is a path-like argument $1. MSYS (but not cygwin) will then
automatically convert $1 to DOS format, before spawning the cmd process
-- which echos the converted path to stdout, where we can grab it. MSYS
(but not cygwin) also turns '//c' into '/c' (the extra slash means
don't use the MSYS mount table to convert this path) -- this is how
you pass win32-style switches to native programs. IIRC, there's some
complicated logic to determine whether a given argument that begins with
two slashes is a switch like /EHsc or a unix-format SMB path like
//server/share/path/to/file.
On cygwin, //c stays //c, and $1 stays in unix format, and 'cmd' gets
very confused by the '//c' non-switch. Bang, you're dead (well,
libtool prints a warning and uses the unix-format path, so...you're a
zombie, and you'll die later).
Maybe if $to_host_path_cmd and $to_host_pathlist_cmd were cached
variables, then folks who (a) know what they are doing, and (b) want to
lie, can do
cygwin$ export lt_cv_to_host_path_cmd=func_cygwin_to_mingw_path_convert
cygwin$ export
lt_cv_to_host_pathlist_cmd=func_cygwin_to_mingw_pathlist_convert
cygwin$ path/to/configure \
--build=i686-pc-mingw32 \
--host=i686-pc-mingw32 \
--target=i686-pc-mingw32
???
=
Now, you're certainly right in one respect: if we can assume that
--build=cygwin --host=mingw means my compiler is a generic
cygwin-hosted mingw cross compiler and NOT I'm using the native mingw
compiler from a weird (cygwin) environment -- then things are a lot
easier. Heck, that probably works already. And I'd test it...if I had an
accessible cross compiler of that sort...
But at present, the cygwin distro does not supply such a beast. It
will, very soon: once the official cygwin gcc-4.[34] packages are rolled
out, they will no longer support -mno-cygwin, so we'll be obliged to
provide a true cygwin-host mingw-target cross compiler just to self-host
and build some of our own tools, like setup.exe.
But...I'm a little confused -- to verify: A normal cross compiler
would itself have been configured as --build=cygwin --host=cygwin
--target=mingw (and if gcc used a libtool with my patch, it'd hit
func_noop_path_convert because $build==$host, which is what we want and
expect). Then, if I wanted to USE that cross-compiler to build pkg X,
I'd configure pkg X as --build=cygwin --host=mingw, so if pkg X used
libtool we'd hit func_cygwin_to_mingw_path_convert etc (which again, is
what we want and expect). Right? Good...
However, all that aside, is func_noop_path_convert a good idea?
Wouldn't it be better to just leave to_host_path_cmd empty in that
case and test for that in func_to_host_path? Or is an unconditional
eval as cheap as an if test -n $foo, in the common case when the
eval isn't needed?
func_to_host_path ()
{
if test -n $to_host_path_cmd; then
eval '$to_host_path_cmd $1'
else
func_to_host_path_result=$1
fi
}
I'm not sure. I was going for clarity of code, and figured we could
determine if any speedups were needed or possible later. To me, it's
much clearer if a $cmd variable is assigned to a func_noop() target, as
opposed to leaving the $cmd
[PATCH] [cygwin]: Add cross-compile support to cwrapper
libltdl/config/ltmain.m4sh: (func_cygpath): New function.
(func_wine_to_win32_path): New function. Refactored from...
(func_msys_to_win32): New function supports converting both
paths and pathlists. Refactored from...
(func_to_host_path): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_path.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_path + func_cygpath.
(func_wine_to_win32_pathlist): New function. Refactored from...
(func_to_host_pathlist): ...here.
[msys-mingw]: Use refactored func_msys_to_win32.
[*nix-mingw]: Use refactored func_wine_to_win32_pathlist.
[cygwin-mingw]: Simplify.
[cygwin-cygwin]: New. Explicit no-op.
[msys-cygwin]: New. Use func_msys_to_win32 + func_cygpath.
[*nix-cygwin]: New. Use func_wine_to_win32_pathlist + func_cygpath.
---
Just as unix - mingw cross builds need special support when
creating the cwrapper source code in order for the cwrapper
to work properly under the wine environment, so too do unix -
cygwin cross builds. However, this led to a lot of duplicated
code, so I refactored a bit.
Now, native cygwin and native mingw both still work ok. What I
can't test is whether I've broken the existing unix - mingw
support. Nor can I actually test the new unix - cygwin
support. I *think* it all should work, but I'd like for
somebody to verify that for me. Please?
NOTE: At present, to use the unix - cygwin support, you *MUST*
have the LT_CYGPATH environment variable exported, containing
the *unix* (that is, $build) path to the cygpath.exe you want
to use. In the final patch, I'll prepare some documentation
to that effect, but right now the implementation is probably
in flux pending feedback.
Here's the comment block in ltmain.m4sh describing this:
# [*] The full *nix path to the cygpath program must be
# specified in the LT_CYGPATH environment variable. This
# is because (a) cygpath shouldn't be in $PATH, because it
# usually lives in cygwin's bin/ directory -- along with
# *cygwin* versions of sed, id, cp. If the unix build
# environment had those programs in its $PATH, many bad
# things could happen. (b) especially in cygwin-1.7, multiple
# installations (with separate mount tables in
# CYGROOT-N/etc/fstab) can coexist on the same Win32
# instance. The cygpath.exe for cygwin installation #N in
# CYGROOT-N/bin automatically deduces the appropriate
# ../etc/fstab file. Therefore, it matters which cygpath.exe
# is used. LT_CYGPATH may be replaced or supplemented by an
# LT_INIT-activated configure option in the future.
In re: LT_INIT, I was thinking maybe LT_INIT([win32-dll cygcross])
where the developers of client packages could enable a configure
option, so that end users could do:
configure \
--host=cygwin \
--cygpath=/opt/cygwin-1.7-unstable/bin/cygpath.exe \
other args
Then, func_cygpath would default to using the specified
cygpath, unless LT_CYGPATH overrides. But I haven't worked
out all the details...eventually I need to set up my own
cygwin-under-wine installation. g Anyway, if cygcross did
not appear as an LT_INIT option, then --cygpath wouldn't
be available (but setting LT_CYGPATH would always work).
Comments? Reviews? *Test Results*?
Oh: one other thing. I know using 'win32' is frowned
upon by the FSF/RMS. But I somehow need to distinguish
between cygwin paths, msys paths, and actual win32
paths. I have several functions now named
func_*_to_win32*(). Got any suggestions? mingw is
actually ambiguous, as it could also refer to unix-style
msys paths. mingw_native might be okay, but it's rather
wordy.
==
Chuck
libltdl/config/ltmain.m4sh | 259 +++-
1 files changed, 209 insertions(+), 50 deletions(-)
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 20ca07b..7677846 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -2557,6 +2557,73 @@ func_emit_wrapper ()
func_emit_wrapper_part2 ${1-no}
}
+# func_wine_to_win32_path arg
+# helper function used by func_to_host_path
+# when $build is neither mingw/msys nor cygwin, and
+# arg must be converted to win32 ($host is mingw or
+# cygwin).
+#
+# result is available in $func_wine_to_win32_path_result
+# result is empty on error (or when arg is empty)
+func_wine_to_win32_path ()
+{
+ lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
+ 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:
+
