autoconf
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]