[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Wrapper executable using wrong path for cross-compiled binaries?
From: |
Ralf Wildenhues |
Subject: |
Re: Wrapper executable using wrong path for cross-compiled binaries? |
Date: |
Mon, 5 Feb 2007 20:55:29 +0100 |
User-agent: |
Mutt/1.5.13 (2006-08-11) |
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