Re: [Patch] cwrapper invokes target directly

[libtool]

On Wed, 30 Apr 2008 10:12:36 -0500 (CDT), "Bob Friesenhahn"
<xxx> said:
> I have a MinGW cross-compiler hosted off of FreeBSD 7.0.  Presumably I 
> can run Wine on it.  I know that Linux has special hooks in order to 
> automatically run Windows executables using Wine.  Is the Wine 
> execution support dependent on this Linux feature?

No, the compile phase requires the $build (linux, unix?) executable
'winepath' only, and does not rely on the binfmt extension present in
linux.  The wrapper itself is already running in the emulation
environment, and uses Win32 spawnv (and other functions from the win32 C
runtime library) to launch the target executable -- within the same
emulation env, so no need for binfmt there, either.  However, actually
running the test suite is going to try to invoke the wrapper.exe, so
that would require binfmt (or another solution; I have ideas).  This may
(or may not) represent a regression from 1.5.x+explicit $TARGETSHELL
specification, I'm not sure.

When I (later) add support for $build=*nix+wine, $host=cygwin
cross-compiles, I'll also need either the 'wine' executable (which
itself is a $build=*nix program) or the binfmt extension, because I need
to execute 'cygpath' *in the $host environment* for step 2 of the
following conversion:

*nix [$build] path --( winepath )--> 
   native win32 [$host] path --( 'cygpath -u' under wine )--> 
      cygwin [$host] path

All of these difficulties and ripples are why I originally thought
'eliminate the wrapper script entirely for $host=cygwin|mingw' was a
libtool-2.4 project.  However, the current libtool-2.2 behavior was an
unreported (!) regression over 1.5.x, and the conversation last week
seemed to imply that it was important enough to try to fasttrack before
2.4...but that doesn't mean it will or can get completely fixed in one
simple patch. It may require iteration and public testing -- over a few
2.2.x releases -- before we get it right. :-(

--
Chuck