Re: [PATCH] [cygwin]: Add cross-compile support to cwrapper

[Peter Rosin]

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 by
the patches in the "Status of the MSVC/MSYS thread") I would like
to reuse your conversion functions for all path conversion needs.
I.e. add func_to_tool_path, that translates paths for easy consumption
by the toolchain, instead of for the cwrapper which is the target of
func_to_host_path.

When on MSYS ($host=mingw, $build=mingw, but scripts running on
MSYS), set both func_to_tool_path and func_to_host_path to
func_msys_to_mingw_path_convert. I.e. scenario (1).

When on Cygwin with a cross compiler ($host=mingw, $build=cygwin,
scripts running on Cygwin and it's possible to execute the output),
set func_to_tool_path to func_noop_path_convert and func_to_host_path
to func_msys_to_mingw_path_convert. I.e. scenario (2).

Ultimately I would like to eliminate fix_srcfile_path, but
fix_srcfile_path is used in func_mode_compile. So, I would like to
move these functions earlier in the script right from the start. But
that will perhaps come with a performance penalty, so perhaps the
list oriented function should remain further down? I don't know
what's best really, I'm just pointing out a future need.

Also, I don't think the patch forwards the new cache variables to
configure runs in the testsuite, isn't that necessary? But now I
looked back and saw that you exported them before you invoked
configure. I guess that works, but it's not as stable as adding
them to $configure_options at the top of tests/testsuite.at.
I really like to be able to add them as arguments to configure
and have them remembered for me for future config.status --recheck
invocations.

Oh, and one more thing, can the to_host_pathlist_cmd variable be
eliminated, and the list conversion somehow abstracted to just
use whatever to_host_path_cmd is currently active? That would be
a nice improvement, methinks. But perhaps it's hard to optimize
out looping in some of the cases?

Cheers,
Peter