[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers
From: |
Stepan Kasal |
Subject: |
Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers |
Date: |
Wed, 11 Apr 2007 19:04:52 +0200 |
User-agent: |
Mutt/1.4.2.1i |
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 <address@hidden>
(_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
autoconf-20070411-cross-test-x.patch
Description: Text document
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers,
Stepan Kasal <=
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Paul Eggert, 2007/04/11
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Ralf Corsepius, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Stepan Kasal, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Keith MARSHALL, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Ralf Corsepius, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Eric Blake, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Keith MARSHALL, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Ralf Corsepius, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Eric Blake, 2007/04/12
- Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Ralf Corsepius, 2007/04/12