Re: more #include_next patches for iconv_open, netinet_in, sys_stat, etc.

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> This is a followup to my previous message about using #include_next to
> fix problems I'm having with GCC 4.2.0 on Debian stable.

Hi Paul,

Not a big deal, but this breaks the part of coreutils' "make distcheck"
that compiles with -Werror -ansi -pedantic:

    ./stdlib.h:33:3: error: #include_next is a GCC extension
    In file included from base64.c:57:

My first thought was to find a way to tell gcc to treat lib/
as a system include directory, which would suppress the warning.
The manual says this:

`-idirafter DIR'
     Search DIR for header files, but do it _after_ all directories
     specified with `-I' and the standard system directories have been
     exhausted.  DIR is treated as a system include directory.

But using -idirafter in that rule resulted in a compilation error
due to a missing S_IXUGO definition, which is used by lib/dirchownmod.c.
That symbol is normally defined via lib/sys/stat.h (and not in my <sys/stat.h>)
but with "-idirafter .", dirchownmod.c was including only the system
header.  I stopped investigating there, at least for now.

For now, I'm just removing the use of -pedantic
in Makefile.maint's my-distcheck rule.

Regardless of how I change the my-distcheck rule, these new uses of
#include_next also break the buildbot's c89-compatibility-checking build:

  http://proulx.com:9000/i686%20c89%20compat/builds/2031/step-compile/0

since it too uses -Werror -ansi -pedantic.