Re: gcc 3.2's cpp breaks configure scripts

[Paul Eggert]

> From: "John David Anglin" <address@hidden>
> Date: Fri, 2 Aug 2002 15:29:29 -0400 (EDT)
> 
> As noted in previous mail, gcc searches both /usr/local/include and
> /opt/gnu/include when it is configured with /opt/gnu, so if you
> add -I/opt/gnu the search order of the two directories is changed.
> This may cause different headers to be used and cause unexpected
> results for other headers depending on how the system is configured.

But GCC warns in many cases where there is no problem.  It is crying
wolf far too often in practice.  People are learning to ignore those
warnings.

I am considering putting a sed filter around GCC to remove these
warnings entirely.  But, more likely, I will install GCC in a
nonstandard place, so that it doesn't include my local equivalent of
/opt/gnu/include by default.  I think that's what Bruno's sysadmin
does.  It is an ugly solution (e.g., it means I'll see
"-I/opt/gnu/include" a lot), but it beats dealing with this hassle all
the time.

If GCC warned only when there was a real problem, a lot of these issues
would go away.

> The main point of debate is whether or not the search order of
> non-fixinclude include directories should by changeable without a
> warning.  Personally, I think it's a mugs game to try rearrange the
> header search order to select a specific set of headers.

In all the cases where I've seen this warning, the header search order
did not matter, and the files behaved identically in "user" and
"system" mode, so GCC's warning was inappropriate.

> > > 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.
> 
> Agreed.  However, I think we have to live with the fixinclude scheme

No, we could fix system includes files on every run of GCC, for
example.  In the old days that would have been impractical for
performance reasons, but nowadays the hassle of dealing with this
problem outweighs any minor slowdowns that would accrue from fixing
system include files dynamically.

There are other possible solutions too, basically building on the
__STDC__ idea that GCC already uses.

This problem is becoming a major inconvenience in using GCC, and it
would be nice if someone would fix it.