Question about feature test macros

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Question about feature test macros

Ken Brown
I was under the impression that 'g++ -std=gnu++11' would enable GNU
extensions, but that doesn't seem to be the case.  Here's a test on Cygwin:

$ cat temp.cc
#include <stdlib.h>

$ g++ -std=gnu++11 -E -dD temp.cc | grep GNU_VISIBLE
#define __GNU_VISIBLE 0

It seems that I have to explicitly define _GNU_SOURCE, even though I've
used -std=gnu++11:

$ g++ -std=gnu++11 -D_GNU_SOURCE -E -dD temp.cc | grep GNU_VISIBLE
#define __GNU_VISIBLE 1

Is this a bug, or am I misunderstanding '-std=gnu++11'?

Ken
Reply | Threaded
Open this post in threaded view
|

Re: Question about feature test macros

Yaakov Selkowitz
On 2017-12-25 16:43, Ken Brown wrote:

> I was under the impression that 'g++ -std=gnu++11' would enable GNU
> extensions, but that doesn't seem to be the case.  Here's a test on Cygwin:
>
> $ cat temp.cc
> #include <stdlib.h>
>
> $ g++ -std=gnu++11 -E -dD temp.cc | grep GNU_VISIBLE
> #define __GNU_VISIBLE 0
>
> It seems that I have to explicitly define _GNU_SOURCE, even though I've
> used -std=gnu++11:
>
> $ g++ -std=gnu++11 -D_GNU_SOURCE -E -dD temp.cc | grep GNU_VISIBLE
> #define __GNU_VISIBLE 1
>
> Is this a bug, or am I misunderstanding '-std=gnu++11'?
Neither gcc -std=gnu* nor g++ -std=gnu++* enable GNU extensions.  What
they do is specify that strict ANSI C/C++ should *not* be used (iow
__STRICT_ANSI__ should not be defined, as it is with -std=c* or
-std=c++*).  With no other FTMs defined, that would expose POSIX-1.2008
plus BSD and SVr4 extensions, but not XSI or GNU extensions.

However, do note that G++ defines _GNU_SOURCE unconditionally for glibc
(and uclibc) based targets[1]  That means that -std=c++* does not work
as documented on those targets, and therefore some C++ packages which
build thereon will not build OOTB on Cygwin.  One day I hope to fix this
for them too, at which point C++ authors are will be forced to start
paying attention to FTMs again.

--
Yaakov

[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57582


signature.asc (235 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question about feature test macros

Ken Brown
On 12/25/2017 11:33 PM, Yaakov Selkowitz wrote:

> On 2017-12-25 16:43, Ken Brown wrote:
>> I was under the impression that 'g++ -std=gnu++11' would enable GNU
>> extensions, but that doesn't seem to be the case.  Here's a test on Cygwin:
>>
>> $ cat temp.cc
>> #include <stdlib.h>
>>
>> $ g++ -std=gnu++11 -E -dD temp.cc | grep GNU_VISIBLE
>> #define __GNU_VISIBLE 0
>>
>> It seems that I have to explicitly define _GNU_SOURCE, even though I've
>> used -std=gnu++11:
>>
>> $ g++ -std=gnu++11 -D_GNU_SOURCE -E -dD temp.cc | grep GNU_VISIBLE
>> #define __GNU_VISIBLE 1
>>
>> Is this a bug, or am I misunderstanding '-std=gnu++11'?
>
> Neither gcc -std=gnu* nor g++ -std=gnu++* enable GNU extensions.  What
> they do is specify that strict ANSI C/C++ should *not* be used (iow
> __STRICT_ANSI__ should not be defined, as it is with -std=c* or
> -std=c++*).  With no other FTMs defined, that would expose POSIX-1.2008
> plus BSD and SVr4 extensions, but not XSI or GNU extensions.
>
> However, do note that G++ defines _GNU_SOURCE unconditionally for glibc
> (and uclibc) based targets[1]  That means that -std=c++* does not work
> as documented on those targets, and therefore some C++ packages which
> build thereon will not build OOTB on Cygwin.  One day I hope to fix this
> for them too, at which point C++ authors are will be forced to start
> paying attention to FTMs again.

OK, thanks for the explanation.  I was thrown off by
https://gcc.gnu.org/projects/cxx-status.html, which says the following
under "C++11 Support in GCC":

    This mode can be selected with the -std=c++11 command-line flag,
    or -std=gnu++11 to enable GNU extensions as well.

But maybe that documentation is intended for glibc platforms.

Ken