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. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
