Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Build failure on current Cygwin, probably caused by force-fed c++98 mode #247
Current git HEAD fails to build on current Cygwin, because fdopen() is not found. That's because configure.ac injects
I see three possible solutions:
I'm trying to understand why
The goal of having
I'll go with
But these days, it has almost entirely adverse effects:
Portability is in fact increased too much, by setting it to C++98. The fact of the matter is that the source code is not written in strictly pure C++98 --- if it were, you would not need any autoconf tests at all.
But the source does use some POSIX-specific extensions, particularly fdopen(). Once you dialed down all the way to
None of the available C++ standards define
/* If nothing (other than _GNU_SOURCE and _DEFAULT_SOURCE) is defined, define _DEFAULT_SOURCE. */ #if (defined _DEFAULT_SOURCE \ || (!defined __STRICT_ANSI__ \ && !defined _ISOC99_SOURCE && !defined _ISOC11_SOURCE \ && !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE \ && !defined _XOPEN_SOURCE)) # undef _DEFAULT_SOURCE # define _DEFAULT_SOURCE 1 #endif ... /* If none of the ANSI/POSIX macros are defined, or if _DEFAULT_SOURCE is defined, use POSIX.1-2008 (or another version depending on _XOPEN_SOURCE). */ #ifdef _DEFAULT_SOURCE # if !defined _POSIX_SOURCE && !defined _POSIX_C_SOURCE # define __USE_POSIX_IMPLICITLY 1 # endif # undef _POSIX_SOURCE # define _POSIX_SOURCE 1 # undef _POSIX_C_SOURCE # define _POSIX_C_SOURCE 200809L #endif ... #if (defined _POSIX_SOURCE \ || (defined _POSIX_C_SOURCE && _POSIX_C_SOURCE >= 1) \ || defined _XOPEN_SOURCE) # define __USE_POSIX 1 #endif ... #ifdef __USE_POSIX /* Create a new stream that refers to an existing system file descriptor. */ extern FILE *fdopen (int __fd, const char *__modes) __THROW __wur; #endif
Also note: all the above is
Not really. It's the core of the issue. Without any
If it does, that's not by any of the code snippets you show.
This doesn't activate, because something is defined:
Consequentially, this does not trigger either.
Precisely. Arguably, it's a bug in glibc if it enables _POSIX_C_SOURCE in the face of
@HBBroeker , as you say, re2c source is not pure C++98, but only library-wise, not language-wise. We do use non-standard library functions, but we also do keep the language subset within C++98 bounds (or try to). So my reasoning here is the following:
However, there is no need to enforce
The true Autotools way is probably to test for each particular non-standard function, not for headers as we do.