Mail Archives: cygwin/2006/04/29/12:46:40
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/
- Raw text -