[cfe-dev] Clang++ always defines _GNU_SOURCE

[Lei Zhang via cfe-dev]

2016-06-14 20:22 GMT+08:00 Lei Zhang <zhanglei.april at gmail.com>:
> 2016-06-14 20:12 GMT+08:00 Joerg Sonnenberger via cfe-dev
> <cfe-dev at lists.llvm.org>:
>> On Tue, Jun 14, 2016 at 06:04:56PM +0800, Lei Zhang via cfe-dev wrote:
>>> 2016-06-14 17:59 GMT+08:00 Ismail Donmez <ismail at i10z.com>:
>>> > Hi,
>>> >
>>> > On Tue, Jun 14, 2016 at 12:54 PM, Lei Zhang via cfe-dev
>>> > <cfe-dev at lists.llvm.org> wrote:
>>> >> 2016-06-14 16:54 GMT+08:00 Eric Fiselier <eric at efcs.ca>:
>>> >>>>  Does libc++ also rely on this macro to work on Linux?
>>> >>>
>>> >>> Yes. Adding -U_GNU_SOURCE during the libc++ build results in a litany of
>>> >>> errors.
>>> >>> The libc++ headers depend on a number of C library symbols that only get
>>> >>> defined when -D_GNU_SOURCE=1 is present.
>>> >>
>>> >> Is it feasible to use some finer-grain control like _ISOC99_SOURCE,
>>> >> instead of resorting to the too versatile _GNU_SOURCE?
>>> >>
>>> >> I'd be willing to work out such a patch to libc++, if it makes sense.
>>> >
>>> > Note that _GNU_SOURCE is more extensive:
>>>
>>> Yes, it requires the use of multiple different finer-grain macros to
>>> replace _GNU_SOURCE, but it's worth the effort IMHO. Simply defining
>>> _GNU_SOURCE may pollute users' code with many unwanted symbols.
>>
>> Compared to breaking lots of applications that expect the GNU symbols by
>> default?
>
> That's a valid point. OTOH, should we encourage applications to use
> GNU symbols with out explicitly defining _GNU_SOURCE? Then what's the
> point of such a macro?

BTW, _GNU_SOURCE is *not* unconditionally defined by gcc/clang when
compiling C code on Linux.


Lei