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 <[EMAIL PROTECTED]>
(_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 <[EMAIL PROTECTED]>
* 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@gnu.org
http://lists.gnu.org/mailman/listinfo/autoconf
