Re: gcc 3.2's cpp breaks configure scripts

["John David Anglin" <dave at hiauly1 dot hia dot nrc dot ca>]

The gcc warning is correct in the cases that I have examined.  I don't
believe that configure should be adding include directories to CPPFLAGS
that are already being searched as system directories by gcc.  This
changes the include search order as noted in the warning and may
cause unexpected results.

One of the culprits in this regard is lib-prefix.m4 (gettext-0.11).
Bruno Haible feels that the solution is to install gcc in a unique
location not used for other packages.  However, this is not recommended
or discussed in the gcc installation notes.  I feel that this is like
confining gcc to the barn.  I like the fact that gcc automatically
searches ${prefix}/include and links in libraries in ${prefix}/lib.

There may be some debate as to what directories gcc should treat
as "system" directories.  However, configure shouldn't change
the default search order of gcc without good reason, irrespective
of whether the directories are truly system directories or not.
this affects gcc's mechanism to fix headers.

The problem has been known for some time and it appears that there
is some kind of standoff between the autoconf macro authors and the
default include search policy used by gcc.  As noted in the subject,
there seems to be an assumption that this is a gcc problem.

I hit this problem again today trying to build textutils-2.1.  I
had built libiconv with the prefix "/opt/gnu/hidden" ("/opt/gnu"
being my normal prefix for most 32-bit packages) to work around
the problem noted below.  However, the autoconf macros used in
textutils-2.1 now do the same thing with the include prefix
for libintl )-:  I originally had a PR on a related matter because
installing libiconv with the same prefix as used for gcc caused
a build failure for gcc.

Possibly, if gcc provided a simpler way to print the search order,
the autoconf macro authors could be persuaded not to append these
directories to CPPFLAGS.  The reasons to do this are documented.
Turning the warning off is not the correct solution, although there
may be some circumstances in which it is emitted when it shouldn't
be.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)