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