Re: Wrapper executable using wrong path for cross-compiled binaries?
Ralf Wildenhues <[EMAIL PROTECTED]> 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:
[EMAIL PROTECTED]:~$ 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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: Wrapper executable using wrong path for cross-compiled binaries?
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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
Wrapper executable using wrong path for cross-compiled binaries?
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:
[EMAIL PROTECTED]:~/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
[EMAIL PROTECTED]:~/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
___
Bug-libtool mailing list
Bug-libtool@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-libtool
