Re: libtool 2.2.2 cross-compile to mingw problems

[Simon Josefsson]

Charles Wilson <address@hidden> writes:

>> 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?
>
> That would be a win32 platform of some kind, because otherwise none of
> this stuff applies. So, are we talking about WinCE or something?

Ah, ok, it wasn't clear to me that all of this was win32-specific.

>> Hm.  Possibly the following would work for me:
>>
>> ./foo.exe --lt-dump-script > tmp
>> mv tmp foo.exe
>>
>> Yes, that appears to work.
>
> Really? I would have thought you'd need to sed the
> WRAPPER_SCRIPT_BELONGS_IN_OBJDIR value to "no" in that case, since
> your wrapper script 'tmp->foo.exe' is /not/ in .libs.

It did work.  There is executable in a .libs/foo.exe.

>>> 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.
>
> Earnie seems to think it *is* a problem with the pty emulation. *If*
> so, it's a new symptom of an old, and known problem with both cygwin
> and msys...native progs (other than cmd.exe itself) have difficulty
> receiving the output from cygwin/msys stdout -- which is an emulated
> pty and NOT a Win32 ConsoleOutputHandle (or whatever).
>
> So *if* that's the problem, it's probably unfixable without major
> surgery to cygwin/msys/wine.  But if not, then perhaps it can be
> fixed. But somebody's going to have to dig very deep to figure out
> which. (Geez: two different OS's [linux, win32], two different
> emulation environments [wine, msys|cygwin], all chained together,
> Debug THAT.)

Yeah, I understand the complexity here.

However, a bash that worked under wine would be useful anyway, I've been
wanting it before, so it would be great to see that happen.

>> I'm using automake 'make check' which is not calling the wrapper script,
>> so this doesn't work.
>
> right.  so, on a cross compile where ( $build != cygwin && $build !=
> mingw ), why do we need a native win32 wrapper executable? Oh, right:
> because $EXEEXT is always going to be .exe if $host = some_win32.
>
> Well, as you point out, there's no reason on a !win32 $build, that
> foo.exe' must be a binary executable.  It can be a shell script.
>
> So maybe if $host is win32, but $build is !win32, we do the following:
>   (1) no cwrapper
>   (2) create the wrapper script as foo.exe
> this is a fairly intrusive change, and will take a while to get
> correct. But I think it has possibilities of satisfying all users.
>
> The only issue left would be this, in the wrapper script;
>
>     exec "$progdir/$program" ${1+"$@"}
>
> How would that work, if what you really want is
>
>     exec "wine" "$progdir/$program" ${1+"$@"}
>
> something like this?
>
>     exec $MY_EMULATION_INVOKER "$progdir/$program" ${1+"$@"}
>
> But surely /that/ problem has been solved for other cross-compile
> setups, where your target is in some emulation environment or on some
> remote machine?  How did it work, before (WAY before, back when there
> WAS no c_wrapper at all)?

This isn't a problem, under Linux there is some binfmt magic so that
executing a *.exe file works directly.  I just type './foo.exe' and the
kernel takes care of launching Wine automatically.

Given how easy it is to set up new kernel handler for other binary
formats, at least under Linux, I think that if it makes things simpler
for libtool, just assume that you can execute any binary without having
to call an interpreter first.

/Simon