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

[Peter Rosin]

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 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
}


Anyway, I have rewritten [1] to hook into the new refactored functions
in your patch via a func_to_tool_path function, controlled with a
to_tool_path_cmd variable. I'll hold that patch until the dust settles,
there are too many pending patches and my git "tree" looks a bit like
a maze...

Cheers,
Peter

[1] http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00117.html