Wrapper executable using wrong path for cross-compiled binaries?

[Simon Josefsson]

Hi!  I'm trying to understand why 'make check' fails for GnuTLS with
automake 1.10 as follows:

...
fixme:msvcrt:_spawnve only trying .exe when no extension given
Wine failed with return code 127
FAIL: ...

Automake 1.10 changed its behavior compared to 1.9.6 (which works
fine) so that 'make check' will now invoke ./program$(EXEEXT) instead
of ./program.  That change appears to be correct, but it causes
problems for libtool.

The problem is in the libtool-generated C code to build a executable
wrapper.  Here is sample output when building the wrapper with
-DDEBUGWRAPPER:

address@hidden:~/src/gnutls/tests$ ./simple.exe
(main) argv[0]      : ./simple.exe
(main) program_name : simple.exe
(find_executable)  : ./simple.exe
(check_executable)  : Z:\home\jas\self\src\gnutls\tests/./simple.exe
(main) found exe at : Z:\home\jas\self\src\gnutls\tests/./simple.exe
(main) newargz[0]   : /bin/sh
(main) newargz[1]   : Z:\home\jas\self\src\gnutls\tests/./simple
fixme:msvcrt:_spawnve only trying .exe when no extension given
Wine failed with return code 127
address@hidden:~/src/gnutls/tests$

For the record, if I invoke './simple' or './.libs/simple.exe'
manually, the self test work fine.

If I understand the wrapper program correctly (which I'm not sure of),
the find_executable function is incorrect.  It causes the program to
think that it should execv("$SHELL
Z:\home\jas\self\src\gnutls\tests/./simple").  That's wrong -- that
path may be correct on the target system (wine), but the execv happens
on the build target.

Then I notice this comment:

          # we should really use a build-platform specific compiler
          # here, but OTOH, the wrappers (shell script and this C one)
          # are only useful if you want to execute the "real" binary.
          # Since the "real" binary is built for $host, then this
          # wrapper might as well be built for $host, too.
          $run $LTCC $LTCFLAGS -s -o $cwrapper $cwrappersource

And that seems correct, and the real cause of my problem.

I can see a few solutions:

1) Use a build-platform specific compiler... however, libtool
   typically doesn't know how to invoke that one, and on weird systems
   there may not even be one.

2) Modify the C wrapper code to deal with this problem and use better
   paths.  I can propose a patch if you believe this is the right
   approach.  Because 1) is really the right solution, even though it
   is complicated, this should be regarded as a hack.

3) Don't use an executable at all, but a simple shell script that
   invokes .libs/$0.  I'm not sure I see a reason to use a executable
   wrapper written in C, anyone else?

Btw, for those looking for a simple work-around: I'm now using this in
my cross-compile build scripts:

  perl -pi -e 's/$run $LTCC/cc/' $builddir/libtool

Thanks,
Simon