Re: gcc 3.2's cpp breaks configure scripts

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

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

Here is the history of the situation as I understand it:

1)  gcc 2.95 and earlier simply added directories to the search list
    without any checks for redundency or changes from system to
    non-system.  As a result, a directory can appear multiple
    times in the search list.

2)  gcc 3.0.x issues warning "ignoring duplicate directory"
    when a duplicate directory is specified and the "-v" option
    is used.

3)  gcc 3.1.x issue warning "cpp0: warning: changing search order
    for system directory" when a system directory is added with
    "-I".  There is no warning about changing the search
    order with "-isystem".  We still have the "ignoring duplicate
    directory" warning with "-v".

4)  gcc 3.3 is the same as gcc 3.1.x except "cpp0" is now "cc1".

All versions search the same set of directories:

  /usr/local/include
  /opt/gnu/include
  /opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include
  /opt/gnu/hppa2.0w-hp-hpux11.00/include
  /usr/include

where "/opt/gnu" was the prefix used to build gcc for the target
hppa2.0w-hp-hpux11.00.

/usr/include is the only directory for which includes are fixed.

libstdc++ headers are installed in /opt/gnu/include unless the
gcc prefix is /usr/local, in which case they are installed in
/usr/local/include.  I stopped installing gcc and packages in
/usr/local since I need to install multiple configurations
(32-bit and 64-bit, etc).  It appears that installing gcc with
--prefix=/usr/local will effectively prevent other installations
from working properly as the g++-v3 headers will always be
found in /usr/local unless the user reorders the system headers.
The same is true for any package which installs headers to
/usr/local.  It might be better if the v3 headers were in
/opt/gnu/lib/gcc-lib/hppa2.0w-hp-hpux11.00/3.1.1/include.

I believe that the automatic search of /usr/local/include is wrong
when gcc was configured with a prefix that is not /usr/local.  This
makes it very difficult for a user to install another version of
gcc in a different location and have it load the correct headers.

Searching for "include_next" in ${prefix}/include, I find two uses
under hppa-linux (a.out.h and limits.h) and none under hppa2.0w-hp-hpux11.
The two headers under hppa-linux are from glibc.  Thus, I agree
that there are very few situations where the headers loaded might
change as a result of reordering gcc's automatic search direcories.

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

1) The header search mechanism is implementation defined and thus
   autoconf and package developers will have to adopt to whatever
   schemes are used in gcc releases.  Possibly, Bruno would accept
   a modified version of my patch where we add gcc system headers
   to CPPFLAGS with "-isystem" instead of dropping them.  This will
   reorder the headers without the warning.  Another alterative
   is to use -nostdinc and -isystem to completely rebuild gcc's
   notion of system headers but this seems more complicated.

2) I would like to see the matter of the /usr/local/include reviewed.
   It definitely shouldn't be the first system include directory
   searched and possibly it shouldn't be searched automatically
   at all when gcc is configured with a prefix other than /usr/local.
   Reducing the number of system directories, simplifies the issues
   of header ordering.  As a result, the autoconf macros are less
   likely to have to add more than one "-isystem" directory and
   determine the ordering needed.  The current gettext macros
   don't attempt to reorder /usr/include.

3) The warning is ambiguous.  Is it about the change in search order
   or the change from a system include to a non-system include directory?
   Since there is no warning when "-isystem" is used, I suspect that
   the warning is about the change to a non-system directory.  In
   that case, we can do without warnings for /usr/local/include
   and /opt/gnu.

4) Let's move the v3 headers to gcc's private include directory so that
   correct versions are automatically used.

Comments?

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