Re: Wrapper executable using wrong path for cross-compiled binaries?

[Ralf Wildenhues]

Hello Simon,

Thanks for the report.

* Simon Josefsson wrote on Thu, Feb 01, 2007 at 10:53:08AM CET:
> 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: ...

That is, cross-compiled binaries and doing 'make check' with the help of
wine, right?  Libtool version?  How exactly did you configure GnuTLS?

> 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.

Hrmpf.

> 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?

Wait a minute.  The usual thing that happens is that libtool builds both
a shell wrapper foo and an executable foo.exe.  The latter calls the
former.  Is there a shell wrapper?  Executing the shell wrapper should
work for you -- does it?


4) Automake should learn how to invoke cross-compiled binaries on a
simulator, or set EXEEXT correctly for this case.  Maybe best if
Autoconf learned it and taught Automake.

5) Libtool should allow to
  execv("$simulator Z:\home\jas\self\src\gnutls\tests/./simple")

6) (4) and (5) combined.

Dunno what's the best way until we have a better one.

Cheers,
Ralf