Hello, let me return to the problem reported on Thu, Mar 29, 2007 by Chris Johns: > The autoconf-2.61 release added a 'test -x' to AC_LINK_IFELSE and that has > broken MinGW based cross-compilers using autoconf packages in MSYS. > > The change is: > > http://cvs.savannah.gnu.org/viewcvs/autoconf/lib/autoconf/general.m4?root=autoconf&r1=1.931&r2=1.932 the changelog entry is: 2006-10-04 Paul Eggert <eggert@xxxxxxxxxxx> (_AC_LINK_IFELSE): Test that resulting file is executable. Problem reported by mwoehlke in <http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00048.html>. I think we shall make a note in the comment above _AC_LINK_IFELSE, e.g.: # Test that resulting file is executable; see the problem reported by mwoehlke # in <http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00048.html>. > RTEMS uses AC_LINK_IFELSE and MinGW cross-compilers fail this test. > > A MinGW compiler cannot set an execute bit on an executable as Windows > provides no support for it. MSYS emulates the execute bit by pattern > matching the file extension (.exe, .bat, .com) so a native Windows compiler > creating a a.exe file works. Here AC_PROG_CC sets $ac_exeext to '.exe' and > AC_LINK_IFELSE creates a .exe file. A MinGW cross-compiler such as one for > RTEMS by default creates 'a.out' so $ac_exeext is ''. > > Is the 'test -x' suitable for MSYS and a cross-compiler ? Indeed, it seems that this combination is not healthy. There does not seem to be a suitable replacement for the 'test -x' which would work universally. And the GNU-on-Woe32 community has not submitted a code which would tell us when 'test -x' should be avoided. But we can pick the third condition of this combination: we might skip the 'test -x' when cross-compiling. The rationale being: 1) Whoever is trying to cross-compile, they usually know what they are doing, so they can live with the less strict protection. IOW, telling the configure where to find the cross-compiler is the least of the cross-compiling skills. 2) The cross-compiler's output has to be ``moved'' (whatever that means) before it can be executed. So it sounds plausible that the cross compiler might leave the output non-executable. A proposed patch attached. Yes, the change is not nice, but would it hurt? Comments welcome, Stepan Kasal
2007-04-11 Stepan Kasal <kasal@xxxxxx> * lib/autoconf/general.m4 (_AC_LINK_IFELSE): Skip AS_TEST_X when cross-compiling. Index: lib/autoconf/general.m4 =================================================================== RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/general.m4,v retrieving revision 1.948 diff -u -r1.948 general.m4 --- lib/autoconf/general.m4 24 Feb 2007 21:48:24 -0000 1.948 +++ lib/autoconf/general.m4 11 Apr 2007 17:01:52 -0000 @@ -2428,14 +2428,23 @@ # ------------------------------------------------------------- # Try to link PROGRAM. # This macro can be used during the selection of a compiler. +# +# Test that resulting file is executable; see the problem reported by mwoehlke +# in <http://lists.gnu.org/archive/html/bug-coreutils/2006-10/msg00048.html>. +# But skip the test when cross-compiling, to prevent problems like the one +# reported by Chris Johns in +# <http://lists.gnu.org/archive/html/autoconf/2007-03/msg00085.html>. +# m4_define([_AC_LINK_IFELSE], [m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl rm -f conftest.$ac_objext conftest$ac_exeext AS_IF([_AC_DO_STDERR($ac_link) && { test -z "$ac_[]_AC_LANG_ABBREV[]_werror_flag" || test ! -s conftest.err - } && test -s conftest$ac_exeext && - AS_TEST_X([conftest$ac_exeext])], + } && test -s conftest$ac_exeext && { + test "$cross_compiling" = yes || + AS_TEST_X([conftest$ac_exeext]) + }], [$2], [_AC_MSG_LOG_CONFTEST $3])
_______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
