This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: compiler standards (and/or min gcc version) supported withinstalled headers ?
On Sat, Dec 29, 2012 at 01:24:56PM -0800, Andrew Pinski wrote:
> On Sat, Dec 29, 2012 at 12:58 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> > On Saturday 29 December 2012 15:44:49 Andreas Schwab wrote:
> >> Mike Frysinger writes:
> >> > On Saturday 29 December 2012 01:26:56 Andrew Pinski wrote:
> >> >> On Fri, Dec 28, 2012 at 10:01 PM, Mike Frysinger wrote:
> >> >> > there are also attributes unconditionally used such as:
> >> >> > stdlib.h: malloc (new to gcc-3.0)
> >> >> > mathcalls.h: nonnull (new to gcc-3.3)
> >> >> > stdlib.h: alloc_size (new to gcc-4.3)
> >> >>
> >> >> unknown attributes are normally ignored even with -W -Wall (though not
> >> >> with -Wattributes) so those should be ok.
> >> >
> >> > yes, but it makes -Werror and such angry,
> >>
> >> Only with -Wsystem-headers.
> >
> > if your gcc supports that, yes :). that flag is new to gcc-3.0.
> >
> > it's probably not as much of an issue for glibc headers, but that flag doesn't
> > work in cases with -I paths that are subdirs of /usr/include. for example,
> > with glib-2.0, you get:
> > $ pkg-config glib-2.0 --cflags
> > -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include
> >
> > so when you do "#include <glib/garray.h>", that isn't considered a system
> > header because it was found via the -I :(.
>
> pkg-config should be using -isystem instead.
Why? glib headers are not system headers. They're third-party library
headers. Why was glib even brought into this discussion about glibc
header behavior? As far as I can tell it's irrelevant.
Rich