[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: |
Keith Marshall |
Subject: |
Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers |
Date: |
Fri, 30 Mar 2007 00:16:23 +0100 |
User-agent: |
KMail/1.8.2 |
On Thursday 29 March 2007 18:04, Ralf Wildenhues wrote:
> * Chris Johns wrote on Thu, Mar 29, 2007 at 08:45:36AM CEST:
> > 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.
>
> Not the one I'm using. Debian testing's cross compiler package
> i586-mingw32msvc-gcc chmod's its executable output to 0755.
With respect, that's not relevant. Chris is not referring to a *nix
hosted compiler targetting MinGW; he's struggling with a Win32 hosted
RTEMS compiler suite, targetting various embedded platforms, if I
understand him correctly. Of course, his following statement is
potentially confusing...
> > RTEMS uses AC_LINK_IFELSE and MinGW cross-compilers fail this test.
...for in reality, MinGW has nothing to do with this, beyond his having
used it to compile his Win32 hosted cross-compiler in the first place.
> Which compiler and version is used?
>
> > A MinGW compiler cannot set an execute bit on an executable as
> > Windows provides no support for it.
>
> But a cross compiler knows that it's a cross-compiler on a unixy
> $build, so in principle it could try, no?
But this isn't a Unixy $build; it's a Win32 $build, with MSYS providing
the (GNU bash) shell environment, to run the configure scripts.
> Anyway, let's see what
> compilers don't do this in practice, theory counts little here.
>
> > Is the 'test -x' suitable for MSYS and a cross-compiler ?
>
> Well, this is AFAIK the first bug report about this.
Well, that doesn't make it any less of a bug, and it's been introduced
only as of autoconf-2.61.
Chris has already raised this issue, on the MSYS list:
http://thread.gmane.org/gmane.comp.gnu.mingw.devel/2290/focus=3922
IMO, it is completely proper for the MSYS implementation of bash to
return false, for `test -x' on any file which isn't runnable on the
Win32 platform. Here, we can't simply lie by setting an executable bit
on a file's directory entry, for there isn't any such bit; executable
status is accorded only to files having an appropriate file name
extension; like it or not, that's just the way it is, in the M$ world.
(Actually, MSYS extends this by also according executable status to
shebanged scripts).
I'm curious as to the rationale behind this decision to insist of linker
output files to pass `test -x'; it must surely break cross-compilation
on any $build platform which doesn't conform to the Unix notion of what
designates a file as executable. Can you point me to some
documentation which explains why it is necessary?
FWIW, adding `as_test_x="test -f"', or anything which doesn't require
`test -x', to config.site seems to be a sufficient workaround to
override this failing test. If `test -x' really is deemed necessary in
the general AC_LINK_IFELSE case, then perhaps it needs some more robust
initialisation logic, when cross-compiling on $build platforms where it
is liable to fail.
Regards,
Keith.
Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers, Paul Eggert, 2007/03/29