This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 6/7] malloc/obstack.h: Remove long obsolete NeXT gcc conditional
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Will Newton <will dot newton at linaro dot org>
- Cc: libc-alpha <libc-alpha at sourceware dot org>
- Date: Mon, 17 Mar 2014 14:36:00 +0000
- Subject: Re: [PATCH 6/7] malloc/obstack.h: Remove long obsolete NeXT gcc conditional
- Authentication-results: sourceware.org; auth=none
- References: <1395059004-20960-1-git-send-email-will dot newton at linaro dot org> <1395059004-20960-6-git-send-email-will dot newton at linaro dot org> <Pine dot LNX dot 4 dot 64 dot 1403171231340 dot 27538 at digraph dot polyomino dot org dot uk> <CANu=Dmh2KRR0aFz+7D-E=rx+kj31W+prP1giRzz39xqCU9UGhA at mail dot gmail dot com>
On Mon, 17 Mar 2014, Will Newton wrote:
> On 17 March 2014 12:32, Joseph S. Myers <joseph@codesourcery.com> wrote:
> > On Mon, 17 Mar 2014, Will Newton wrote:
> >
> >> This fixes a warning introduced with -Wundef, but in general there
> >> is no point supporting this long obsolete configuration.
> >
> > Have you confirmed that it's outside the scope of what gnulib tries to
> > support (since this code is shared with gnulib - the only reason for glibc
> > headers to support GCC versions before 2.7, as they didn't support any
> > platforms now supported by glibc)?
>
> It's not clear to me exactly which platforms gnulib supports but
> NeXTStep is not in the list of target platforms in the gnulib docs.
> How are changes to this code handled? It doesn't appear that there is
> a regular sync of code in either direction.
In principle, code from glibc should be updated in gnulib via
srclist-update. In practice, all the $LIBCSRC entries in srclist.txt are
commented out at present - and there are many files in gnulib with
comments stating "This file is part of the GNU C Library." (or similar,
possibly with the phrase "GNU C Library" split over two lines - something
to watch out for when identifying such files) and no mention in
srclist.txt at all. It would be a useful project to identify all gnulib
files based on glibc and merge the individual logical changes to those
files in gnulib back to glibc, so that the files can be fully in sync
again. Where the changes clearly do not affect builds as part of glibc,
getting them into glibc shouldn't involve more than a routine coding style
review.
--
Joseph S. Myers
joseph@codesourcery.com