Re: gcc 3.2's cpp breaks configure scripts

[John David Anglin]

> 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.

Which cases are these?  Irrespective of whether or not the directory
is truly a "system" directory, the patch detects directories that
gcc will search.  A "-I" is unnecessary for these directories unless
you actually want to change the search order.   This is dangerous
unless you have intimate knowledge of how the system is configured.

Gcc has a predefined search order for its "system" directories
and I have yet to see a convincing reason why its necessary to change
this order for building packages which use the gettext macros.  The
only situation where I can see a problem is when a header is
installed in two of the directories searched automatically by gcc
and the user attempts to select the one that is searched second.
With my patch, you will get the header in the first directory
rather than the one in the second directory and this could cause
a problem due to inconsistent versions.  I would prefer configure
checked for this than give up the predefined search order.

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.

> 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.

Yes, that's a valid point.  In the case at hand, none of the above
were installed in a fixincludes directory.  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.

> > 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
and the fact that gcc has a set of include directories that it searches
in a predefined order.

Dave
-- 
J. David Anglin                                  address@hidden
National Research Council of Canada              (613) 990-0752 (FAX: 952-6605)