Dave Korn wrote: > > (Why #define says __CYGWIN__ and gcc -v says something else is > > silly.) > > No it isn't. Your assumption that the two have to be in some way related is > silly. As is attempting to parse the output from "gcc -v" to detect a given > target rather than using one of the predefined macros, which is what they are > for and how it is supposed to be done. The output from "gcc -v" is for > *humans* to read, and version strings are allowed to have free-format text and > no guarantees are provided regarding the content or formatting of that text or > how it may or may not change in the future.
First, I agree with most of the points Dave has made - cygwin gcc is a single package (hence -v output that uses a phrase intended to show that both cygwin native and mingw cross-compilation is supported, and in no way was intended to slight cygwin). I agree that Lloyd is reading too much into the current output of -v. I also agree that -v is not the appropriate way to determine what the compiler supports - on cygwin, gcc without options will compile a cygwin native executable, and #define __CYGWIN__ to a nonzero value, while gcc with the -mno-cygwin option will cross-compile mingw native executables, and leave __CYGWIN__ undefined. Using the output of -dumpmachine, or better yet, using the autoconf tradition of compiling a test program to see what the actual compiler's behavior is instead of relying on version strings, is more appropriate. However, I feel that the output of gcc -v is not entirely freeform, because part of it is also used in gcc --version. In this recent autoconf thread, http://lists.gnu.org/archive/html/autoconf/2006-04/msg00116.html, it was pointed out that Debian has a similar bug where their gcc's version output violates GNU coding standards by not ending in a version number. Gerritt, I would suggest that the next time you package gcc for cygwin, that you alter the version string such that it ends in a version number, perhaps something like: gcc (GCC) 3.4.4 (cygwin/mingw special, gdc 0.12, dmd 0.125) 3.4.4-2 Now, as to the real question about d_ino semantics. Cygwin versions up to 1.5.18 declared d_ino, but were buggy in their implementation such that d_ino sometimes disagreed with st_ino (for example, on NTFS drives). This bug forced me to compile cygwin coreutils as though d_ino did not exist, since there are applications that do care about the correct value of d_ino. Cygwin 1.5.19 removed the declaration of d_ino altogether, as permitted by POSIX, because of this bug. Therefore, if your app fails to compile when d_ino is not present, it is a bug in your app for disobeying POSIX/SUSv3, which explicitly state that d_ino is optional. Cygwin 1.5.20 will introduce a patch that ensures d_ino is always correct, at the expense of a slowdown in cases where Windows is not helpful (mainly when dealing with a drive on NT machines), so it will reintroduce a d_ino declaration in the headers. You can test this out now by using a cygwin snapshot. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
