Re: libtool 2.2.2 cross-compile to mingw problems

[Simon Josefsson]

Charles Wilson <address@hidden> writes:

> Simon Josefsson wrote:
>> Charles Wilson <address@hidden> writes:
>>>> How is this intended to work?  You can't execute bash scripts under
>>>> Windows nor Wine, as far as I know.
>>> Yes and no. You need some win32 shell installed in your Wine
>>> environment.  (For native win32 builds, this is no problem: if you are
>>> running libtool, you have a shell).
>>
>> That seems to be a regression from libtool 1.5.x: I haven't needed
>> anything but Wine itself to build and run programs before.  Libtool
>> 1.5.x used a shell script which used the native shell, rather than
>> requiring a shell for the target.
>
> It probably is a regression, but it's not one that can be easily
> fixed. The reason we use a binary wrapper is as follows (taken from
> http://lists.gnu.org/archive/html/libtool-patches/2007-04/msg00050.html,
> and rewritten slightly):
>
> In earlier libtool, on cygwin/mingw, the following files are created:
>    foo.exe   -- a [win32] wrapper executable, that launches...
>    foo       -- a wrapper scripts, which sets env vars and launches...
>    .libs/foo.exe -- the actual target executable
>
> The reaons for this old arrangement was we needed a '.exe' in the
> actual object directory, so that 'make' would understand that
> target$(EXEEXT) had already been built.  Otherwise, 'make install'
> would always relink, 'make check' would relink, and sometimes
> pathological cases would get into an infinite relinking loop.
>
> However, because we still had the original wrapper script -- and there was 
> nothing win32-specific about it; it's just a simple sh script -- 
> cross-compiler folks just ignored the target$(EXEEXT) wrapper, and
> invoked the shell wrapper directly.
>
> However, the presence of both foo and foo.exe in the same directory
> causes some problems with coreutils/shells' "autodetect .exe's" logic
> under "native" MSYS and "native" Cygwin.  And it's downright unusable
> when the cygwin "transparent_exe" option is active.
>
> So, eventually we decided to eliminate ./foo entirely on these
> platforms, and rely entirely on ./foo.exe and .libs/foo.exe (with
> perhaps some other files in .libs/)

Sure, and I have no problem with dropping the shell script 'foo'.  I
don't think I have been using it, and if I were, that would be a bug I
should fix (I should call foo.exe instead).  I am primarily wanting to
get 'make check' produced by Automake to work (and it calls foo.exe and
never uses the 'foo' shell script).  I am sorry if I wasn't clear about
this.

As far as I understand the new approach, it is:

  foo.exe - a [win32] wrapper executable, that launches...
  $TARGETSHELL .libs/foo_ltshwrapperTMP -- which sets env vars and launches...
  .libs/foo.exe -- the actual target executable

Requiring a working bash.exe on the target host seems to me be the
problematic part, and that is a regression over libtool 1.5.x.  What if
you are cross-compiling to a platform that doesn't have a POSIX shell?

Implementing what the shell script does directly in foo.exe seems like a
better solution to me, and seems to be what you suggest too.  I'll try
to get some work-around working with libtool 2.2, or revert to libtool
1.5, meanwhile

> Putting a shell-script "foo" back into the main directory would
> re-impose these "autodetect .exe" issues on the native platforms.
>
> There IS an option that will work on cross-compile hosts which are not
> confused by the presence of foo.exe and foo in the same directory
> (it's a bit ugly):
>
> $ wine ./foo.exe --lt-dump-script |\
>   sed -e 
> 's/^WRAPPER_SCRIPT_BELONGS_IN_OBJDIR.*$/WRAPPER_SCRIPT_BELONGS_IN_OBJDIR=no/' 
>> ./foo
>
> And now you can use foo as you like. Simpler, but still awkward at present:
>
> $ wine ./foo.exe --lt-dump-script > ./.libs/foo
> $ .libs/foo

That works in the sense that the application starts, thanks for the
pointer.

However, I'm not sure how it solves my problem, which is to get 'make
check' to work.  Automake still invokes foo.exe, and that fails with
libtool 2.2.

Hm.  Possibly the following would work for me:

./foo.exe --lt-dump-script > tmp
mv tmp foo.exe

Yes, that appears to work.  The remaining (and likely the biggest)
problem is to integrate this with the automake 'make check'
infrastructure.  Possibly I could use a TEST_ENVIRONMENT hook, but it is
ugly.  Other ideas?

>> However, I'm not sure my sh.exe is working properly:
>>
>> address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ wine C:/MinGW/bin/sh.exe 
>> --help
>> Wine failed with return code 1
>> address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ 
>
> And that, I don't understand. It's not just some weird issue with the
> bash stdout going to an MSYS-emulated pty, that has trouble hooking up
> to the wine-emulated Win32 Console Handle, that has trouble hooking up
> to the linux pty -- because even if all that were true, bash --help
> should exit with 0, and wine should propagate that success code.  Even
> if you can't see stdout from win32-bash.
>
> Rouman Petrev posted a bug report to the mingw-users list; we'll see
> what kind of response that generates.

Great.  I hope we can solve it this way.  I liked your TARGETSHELL
work-around better.

> But for now, you should be able to use the --lt-dump-script workaround
> for all your wrapped executables, and then just use the wrapper
> *script* as you are used to.

I'm using automake 'make check' which is not calling the wrapper script,
so this doesn't work.

/Simon