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