Re: gcc 3.2's cpp breaks configure scripts

[Bruno Haible]

John David Anglin writes:
> Enclosed is a patch to the gettext macros lib-link.m4 and lib-prefix.m4
> to prevent them from appending GCC system directories to CPPFLAGS.  It
> uses "gcc -v -E" and checks for the warning.

The patch does the wrong thing in half of the cases.

If the added directory is one of the directories on which fixincludes
is run, then
  1. gcc's warning is justified,
  2. Users shouldn't install additional packages (such as libintl,
     libiconv etc.) in this directory. It won't work because the
     include file seen by gcc might be the fixincluded one, which
     represents a different version of the package than the one
     which is being installed as a library.
     It'd be good if the GCC documentation mentioned this pitfall.

If the added directory is not a fixincluded one, then there is no
reason for GCC warning - except for Jakub's arguments.

Jakub Jelinek writes:

> > you're saying that adding -I/usr/include (or similar) can cause libstdc++ 
> > headers to break due to the way they use #include_next?
> Yes.

Then indeed it would be wrong to add -Idir to the command line. But
then also, you should document in the GCC documentation that users
should not install packages in these directories. Because any freshly
installed .h file in such a directory may be hidden by the ones in
gcc's private gcc-lib/platform/version/include directory, which are
older but have not been updated.

In this case, it'd be best for autoconf macro authors if gcc provided
an easy to use, documented way to test whether a directory is
forbidden for -I or not. I'd then use this test in two situations:
  1) When searching for a library and its include files, this
     directory shall be skipped, even if it equals $prefix/include,
  2) When installing a library, configure will refuse to install in
     such a forbidden directory.

> Also, -I/usr/include changes the status of /usr/include headers from
> system headers to user headers, thus you may get warnings (or errors
> with -Werror) where you otherwise would not get any.

This is an indication that cpp's heuristic to distinguish "user" and
"system" heads is wrong.

Bruno