From: ericblake AT comcast DOT net (Eric Blake)
To: "'Lloyd Wood'" <L DOT Wood AT surrey DOT ac DOT uk>,
   "'Chris Elliott'" <cl3ellio AT interchange DOT ubc DOT ca>
Cc: cygwin AT cygwin DOT com, geomview-users AT lists DOT sourceforge DOT net,
   geomview-devel AT lists DOT sourceforge DOT net
Subject: RE: Geomview & Cygwin setup [Attn gcc maintainer]
Date: Sat, 29 Apr 2006 16:46:31 +0000
Message-Id: <042920061646.11264.445398670004ADDD00002C0022092299270A050E040D0C079D0A@comcast.net>
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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/