| Message ID | 1395059004-20960-6-git-send-email-will.newton@linaro.org |
|---|---|
| State | New |
| Headers | show |
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)?
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.
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.
diff --git a/malloc/obstack.h b/malloc/obstack.h index 85472f9..0fd623e 100644 --- a/malloc/obstack.h +++ b/malloc/obstack.h @@ -249,13 +249,6 @@ extern int obstack_exit_failure; #define obstack_memory_used(h) _obstack_memory_used (h) #if defined __GNUC__ -/* NextStep 2.0 cc is really gcc 1.93 but it defines __GNUC__ = 2 and - does not implement __extension__. But that compiler doesn't define - __GNUC_MINOR__. */ -# if __GNUC__ < 2 || (__NeXT__ && !__GNUC_MINOR__) -# define __extension__ -# endif - /* For GNU C, if not -traditional, we can define these macros to compute all args only once without using a global variable.