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

[Simon Josefsson]

Ralf Wildenhues <address@hidden> writes:

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

Yes.

> Libtool version?

Debian:

address@hidden:~$ libtool --version
ltmain.sh (GNU libtool) 1.5.22 Debian 1.5.22-4 (1.1220.2.365 2005/12/18 
22:14:06)

> How exactly did you configure GnuTLS?

./configure --host=i586-mingw32msvc --build=i686-pc-linux-gnu

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

Possibly I could set $SHELL to 'wine' before calling the wrapper
executable, although that may break other things.

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

Yes -- executing the shell wrapper works fine.  Automake < 1.10
invokes the shell wrapper on 'make check'.  However, automake >= 1.10
invokes the executable foo.exe instead.

I believe automake 1.10 is correct to run the executable with EXEEXT.
If libtool weren't used, automake couldn't run any script, it could
only run the executable called foo$(EXEEXT).

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

I believe Automake already invoke the cross-compiled binary correctly.
However, it is the cross-compiled libtool wrapper binary that doesn't
work correctly.  If libtool's wrapper executable source code were
improved, or if it was built with the build-platform compiler, it
would work.

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

Could work, although that would hard-code the simulator in the build
systems.  With the linux kernel, it seems easy to add new file
formats, and have them be invoked by any simulator, so I'd prefer that
approach.  But for other systems and other people, 5) may be a useful
addition.

/Simon