This is the mail archive of the
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.
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Carlos O'Donell <carlos at redhat dot com>
- Cc: Zack Weinberg <zackw at panix dot com>, <libc-alpha at sourceware dot org>
- Date: Wed, 21 Sep 2016 19:59:00 +0000
- Subject: Re: [PATCH 06/13] Installed header hygiene (BZ#20366): Macros used in #if without checking whether they are defined.
- Authentication-results: sourceware.org; auth=none
- References: <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <alpine.DEB.email@example.com> <firstname.lastname@example.org>
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
Joseph S. Myers