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
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-libtool
