Re: libtool 2.2.2 cross-compile to mingw problems

[Simon Josefsson]

Charles Wilson <address@hidden> writes:

>> As far as I can understand from the .libs/lt-certtool.c code, it writes
>> a bash script into .libs/certtool_ltshwrapperTMP and then tries to
>> execute that.
>>
>> 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.

If it hasn't been clear, I'm cross-compiling from debian x86 to mingw.

> Anyway, the following bits in ltmain kick in, which try to determine
> the name of the shell that the (win32 wrapper executable) should
> invoke, as if:
>    system("some-win32-sh.exe the-wrapper-script <other args?>")
>
>
> case "$host" in
>   *mingw* )
>     # awkward: cmd appends spaces to result
>     lt_sed_strip_trailing_spaces="s/[ ]*\$//"
>     lt_newargv0=`( cmd //c echo $SHELL | $SED -e 
> "$lt_sed_strip_trailing_spaces" ) 2>/dev/null || echo $SHELL`
>     case $lt_newargv0 in
>       *.exe | *.EXE) ;;
>       *) lt_newargv0=$lt_newargv0.exe ;;
>     esac
>     ;;
>   * ) lt_newargv0=$SHELL ;;
> esac

Is the result of this operation printed anywhere, during ./configure?

> (5) Also, there is a hidden assumption that the win32 shell that
> should be used by Wine has the same name as the host shell.
>
> Now, I can probably address some of these isses -- but the real
> solution is actually found in the enclosing block of code:
>
> if test -n "$TARGETSHELL" ; then
>   # no path translation at all
>   lt_newargv0=$TARGETSHELL
> else
>  <the stuff above>
> fi
>
> If, when compiling your code, you have TARGETSHELL defined in your
> envinrment to the win32 (e.g. internal Wine) path, then the wrapper
> executable will use that. That is,
>
> export TARGETSHELL="C:\\Util\\gnuwin\\bin\\sh.exe"
> export TARGETSHELL="C:\\msys\\1.0\\bin\\sh.exe"
>
> *before* building your project.
>
> Assuming that setting TARGETSHELL solves your problem, I think
> something like the following (untested) patch might be useful. The
> second hunk tries to address points (1), (2) and (3) above. This still
> won't fix your problem -- but TARGETSHELL should -- because you'd
> really just end up trying to exec the linux shell from the
> (win32-native, Wine) wrapper exe: I don't know if Wine lets you do
> that.

This seems like a reasonable workaround, but it seems the \ escaping
didn't work out well.  I got plenty of errors during build:

./.libs/lt-hostname-check.c:295:34: warning: unknown escape sequence '\M'
./.libs/lt-hostname-check.c:295:34: warning: unknown escape sequence '\s'
./.libs/lt-hostname-check.c:358:28: warning: unknown escape sequence '\M'
./.libs/lt-hostname-check.c:358:28: warning: unknown escape sequence '\s'

However, using forward slashes seems to work better, but not fully, I
now get:

address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ ./certtool.exe 
(main) argv[0]      : ./certtool.exe
(main) program_name : certtool.exe
(find_executable)   : ./certtool.exe
(check_executable)  : 
Z:\home\jas\gnutls4win\build\gnutls-2.3.8\src/./certtool.exe
(main) found exe (before symlink chase) at : 
Z:\home\jas\gnutls4win\build\gnutls-2.3.8\src/./certtool.exe
(main) found exe (after symlink chase) at : 
Z:\home\jas\gnutls4win\build\gnutls-2.3.8\src/./certtool.exe
(main) libtool shell wrapper name: certtool_ltshwrapperTMP
(make_executable)   : 
Z:/home/jas/gnutls4win/build/gnutls-2.3.8/src/./.libs/certtool_ltshwrapperTMP
(main) newargz[0]   : C:/MinGW/bin/sh.exe
(main) newargz[1]   : 
Z:/home/jas/gnutls4win/build/gnutls-2.3.8/src/./.libs/certtool_ltshwrapperTMP
Wine failed with return code 1
address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ 

It should have printed a --help screen.

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$ 

The other binaries installed from msys works though:

address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ wine C:/MinGW/bin/gcc
gcc: no input files
Wine failed with return code 1
address@hidden:~/gnutls4win/build/gnutls-2.3.8/src$ 

Possibly the shell doesn't print anything by default?

I'll see if I can get the shell working.  Any ideas to help me are most
appreciated.

Thanks,
/Simon