autoconf-patches
[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: Eric Blake
Subject: Re: autoconf-2.61's AC_LINK_IFELSE with MinGW cross-compilers
Date: Thu, 12 Apr 2007 11:57:16 -0600
User-agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.10) Gecko/20070221 Thunderbird/1.5.0.10 Mnenhy/0.7.5.666

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 4/12/2007 11:17 AM:
> 
> What matters is the executable bit. AFAICT, even old FAT had them.

No, FAT has no such thing.  After all, we are talking about a file system
with 2 second timestamp granularity.  FAT lacks the traditional 9
rwxrwxrwx bits of Unix, so they must be faked.  There is a read-only bit
(one, not three), and a system, hidden, and archive bit  But those four
bits is all, there is no executable bit.  Yet it doesn't bother Microsoft,
because native programs are executable based solely on their extension.

Both cygwin and MinGW fake unix bits on FAT by calling something
executable if it knows it can execute it.  There is nothing inherently
wrong in faking something that is not there; it is only wrong to expect
this faking to work when there is no way that cygwin can execute the file
because it is a cross-compiled image designed for a different
architecture.  Technically, cygwin 'text -x' could be made smarter (a la
file(1)) to read the first few bytes of every file to see if it matches
known patterns of ELF and other executable formats, but this would
dreadfully slow down performance (and windows is already slow enough).
And since cygwin is open source, you could write such a patch to do this;
but please don't expect me to apply it on my use of cygwin.

> Could you please elaborate why autoconf would a need any -x check at
> all?

Reread this thread.  In a NATIVE environment (using cygwin to compile
cygwin executables, or using mingw to compile mingw executables), 'test
- -x' works correctly, AND it is a good sign that the compiler is not
broken.  There are documented cases of broken compilers that create
partially formed files, but leave them non-executable, when encountering a
compilation error.  In other words, mere existence checks are not enough
to detect that a compile failed, you also need an executable check.  This
check is still needed for native compiles because so many more developers
actually do native compiles, and there are so many more brands of native
compilers than cross-compilers.

> IMO, it is playing with symptoms. Either this -x is always relevant or
> it is never relevant.

I stick with the current outcome of this thread.  -x is half-relevant -
always relevant to native compiles, and never relevant to cross compiles.

> IMO, the reports proves Cygwin's and MinGW's "test -x" to be defective.

No, it proves that the Microsoft FAT file system is defective, for not
providing mode bits.

> 
> As a consequence of this, this render using "test -x" on both Cygwin and
> MinGW a random accident and (in our case) qualify Cygwin and MinGW as
> non-suitable hosts for cross-compilation.

cygwin is quite useful as a cross-compilation environment (a bit slow, but
not broken like you make it out to be).  And while mingw as a
cross-compiler is rather more difficult, there are some die-hards out
there making it work.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFGHnL884KuGfSFAYARAhpbAKDTxCidNQHR+hjLdI1Oe9ossjxa2gCfYy5A
jaU5tAvLeNgegH202i8N6MY=
=ptYv
-----END PGP SIGNATURE-----




reply via email to

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