Mail Archives: djgpp/2020/11/30/14:59:57
On 11/30/20 9:00 PM, Eli Zaretskii (eliz AT gnu DOT org) [via djgpp AT delorie DOT com] wrote:
>> From: "Andris Pavenis (andris DOT pavenis AT iki DOT fi) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
>> Date: Mon, 30 Nov 2020 20:25:13 +0200
>>
>> On 11/30/20 7:52 PM, DJ Delorie wrote:
>>> Best thing to do is to file a bug with gcc and let them language-lawyer
>>> it out.
>> I mentioned as example the behavior in Linux. In this case its glibc implementation stuff not even
>> gcc one:
>>
>> - gcc or clang only defines __STRICT_ANSI__
>>
>> - glibc headers causes definitions of pid_t and ino_t and other stuff not to be excluded
>>
>> Another question whether specifying for example -std=c++11 (which implies __STRICT_ANSI__) also
>> implies ANSI CÂ for used C headers.
> IME, no useful program can be compiled with strict ANSI, so using
> -std=c++11 when building a compiler is counter-productive. I'd
> suggest to try -std=gnu++11 instead.
Seems to come from use of
https://github.com/autoconf-archive/autoconf-archive/blob/master/m4/ax_cxx_compile_stdcxx.m4
Familiar nuisance: nice C++ standard support detection but result return way is bad: it causes
-std=... appended directly after compiler path before other options. Even overriding CXX for
Makefile may break stuff.
Noticed it in one my own project. Cannot build it for DJGPP for testing (threads, jne). Could
however try yto check whether I can reasonably easy get it to replace std=c++11 with gnu++11
(easier with project than builds under 1 minute)
From the other side Linux do not follow these restrictions. As result developers do not even
notice a problem. Even my earlier mentioned project builds for Linux without problems when c++17 is
specified
Andris
PS. Checked: Replacing 'AX_CXX_COMPILE_STDCXX_17([noext], [optional])' with
'AX_CXX_COMPILE_STDCXX_17([ext], [optional])'
causes 'clang++ -std=gnu++17' to be used instead of '-std=c++11'
- Raw text -