Re: libtool 2.2.2 cross-compile to mingw problems

[Ralf Wildenhues]

* Charles Wilson wrote on Thu, Apr 24, 2008 at 01:31:11AM CEST:
> Roumen Petrov wrote:
>> why libtool do not create (on other build platforms) wrapper scrip as 
>> before ? In this case test.exe can try to run it directly without to 
>> create .libs/<PROGRAM>_ltshwrapperTMP.
>
> This is not going to change, for native builds. It was *always* a really  
> *bad* idea, back in 1.5.0pre, to have both foo.exe and foo in the same  
> directory. On build platforms like win32 that allow  
> exec()/system()/CreateProcess()/what-have-you, when called with the  
> argument "foo", to succeed when only the file "foo.exe" exists.
>
> However, we *can* detect that we're cross-compiling. And wrappers are  
> only intended for use by someone with access to the build directory and  
> build platform...so, maybe we should use $build instead of $host to  
> determine whether needs_c_wrapper?
>
> Any thoughts on that, Ralf, Peter?

Here's my general take on this code.  It has several problems:

1) Cross compiling from GNU/Linux to MinGW currently needs a MSYS shell
on the $host system.  That is a usability regression which should be
eliminated if at all possible.

We have freedom to check $build and use its shell interpreter for
executing uninstalled scripts.

2) Depending upon
  - whether the user specified '-o foo' or '-o foo.exe'
  - other details (such as whether we link against an uninstalled
    library at all)
we may be generating 'foo' or 'foo.exe', esp. with a cross compile.
This is unfortunate.  I'm not sure what the best strategy is.
Non-automake users may have different needs than automake users.
One solution may be just to adjust the documentation (but not doing
anything here is wrong!)

3) Independently of w32: we need to make generation of both binary and
shell wrappers atomic.  Rationale: when the user executes two instances
of the uninstalled wrapper, we must not fail.  See here for more
information: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752>.

4) Generating some wrapper each time is slow.  Not a show-stopper,
but a usability regression.  I have forgotten why a second wrapper
script, once generated, cannot remain below $objdir, but is removed
each time again.

I'm sure I've forgotten more stuff here.

Cheers,
Ralf