Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers

[Ralf Corsepius]

On Fri, 2007-03-30 at 00:16 +0100, Keith Marshall wrote:
> 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. 
Pardon, but I have to disagree on this. A file being marked as
"executable" doesn't mean it can be run in this particular native
environment. 

It means a file is meant to be run from the file system it is located
on.

This is of particular importance for cross-compilers: They produce
executables to be run elsewhere. I.e. these files need to be marked
'+x'ed. [1]

>  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).
Well, as I read all this, MSYS's "test" diverges from a *nix's "test"[2]

Ralf

[1] A classical situation to meet this is a networked mounted filesystem
being shared between several OS and using a cross compiler on one system
to build executables for other OS.

[2] An RTEMS user using a Cygwin host, reported this issue also to occur
on Cygwin when using a FAT32 filesystem but not to occur with an NTFS
filesystem.