This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 06/13] Installed header hygiene (BZ#20366): Macros used in #if without checking whether they are defined.
On 09/21/2016 03:59 PM, Joseph Myers wrote:
> On Wed, 21 Sep 2016, Carlos O'Donell wrote:
>
>> On 09/21/2016 02:05 PM, Joseph Myers wrote:
>>> On Wed, 21 Sep 2016, Carlos O'Donell wrote:
>>>
>>>> At a high level I would expect _LIBC to always be defined as either 0 or 1.
>>>
>>> _LIBC is effectively with external code, because it's used (with #if) in
>>> code shared by gnulib. So we can't change its semantics like that;
>>> defining to 0 with installed glibc would break building gnulib.
>>
>> Isn't that just a normal coordination issue with gnulib?
>
> No. It should be possible to build existing versions of GNU software, and
> other packages using gnulib, with new versions of glibc, without needing
> to wait possibly years for loads of packages to have new releases with
> updated gnulib. Occasionally a new glibc may break a few external
> packages and require coordination with them, but we shouldn't do things
> that would cause the sort of global breakage of most gnulib-using software
> that would result from changing the public _LIBC interface with external
> code.
You use the words "should" twice, which matches my expectation here, that
we would like it to work, but by coordinating with gnulib we might change
it in the future given a good enough reason. I call this a coordination
issue with gnulib.
In this situation I see no case to be made for changing _LIBC's behaviour.
I think we are both in agreement. Perhaps I sounded too cavalier in claiming
it was "just" a coordination issue.
--
Cheers,
Carlos.