Re: gcc 3.2's cpp breaks configure scripts

[Zack Weinberg]

On Sat, Aug 03, 2002 at 05:42:11PM -0400, John David Anglin wrote:
> 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.

Correct.

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

Yes.  (cpplib has done that for ages; you will, frex, get the warning
with some 2.96 and 2.97 era compilers.)  No one has ever objected to
this as far as I know.

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

Yes.  The warning was added in July 2001 by Nathan Sidwell.  The
original message proposing it is
http://gcc.gnu.org/ml/gcc-patches/2001-05/msg00466.html - yes, May;
the discussion broke off and was resumed in July, starting at
http://gcc.gnu.org/ml/gcc-patches/2001-07/msg00046.html

There is not much discussion of the rationale for the patch in this
context, just a mention of problems with libstdc++.  Nathan, would you
mind expanding a bit?

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

Yah.

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

As far as I can tell, 2.95 and 3.0 would not have searched
/opt/gnu/include (i.e. $(prefix)/include) at all.  Per Bothner 
changed this in September 2001, with this patch:
http://gcc.gnu.org/ml/gcc-patches/2001-09/msg00519.html
It was generally agreed that not searching $(prefix)/include was a
bug.

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

More accurately, $(SYSTEM_HEADER_DIR) is the only directory for which
includes are fixed.  There is $(OTHER_FIXINCLUDES_DIRS), but nothing
uses it.  SYSTEM_HEADER_DIR is normally /usr/include, but in a cross
compiler it's $(exec_prefix)/$(target_alias)/sys-include, and several
target fragments override it (incorrectly; they should be changing
NATIVE_SYSTEM_HEADER_DIR...)

> 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 there were other bug reports requesting this move, too.
You'd have to take that up with the libstdc++ people though.

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

There are two very good reasons why /usr/local/include is searched
independent of whether it's $(prefix)/include: First, if you are
building with prefix=/usr, (or prefix="", if you're those crazy Hurd
people) you still want /usr/local/include searched.  Second, if you
are a user installing gcc in their home directory (on a multi-user
system, where you don't have write privs anywhere else), again you
probably still want /usr/local/include searched.

Could you expand a bit on your assertion that this makes it difficult
for a user to install gcc in an unusual location and have it find the
correct headers, please?  I do not see how the problem arises.

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

Correct; see above.

>    In that case, we can do without warnings for /usr/local/include
>    and /opt/gnu.

I do not see how this follows.  The problems caused by
-I <dir on system path> are not merely because of failure to pick up
fixincluded headers.  For instance, Dan Jacobowitz points out that
-I/usr/include can cause havoc when used with a cross compiler; it
seems to me that -I/usr/local/include could cause just as much havoc.
(He wanted these to warn in a cross configuration, which I must
confess I don't see any way to do - how do we know that
-I/gltz/quux/include happens to contain headers for the wrong target?

My inclination, for the record, is to do nothing until all parties
come to an agreement on what GCC's behavior _should_ be.  At present,
I suspect that any patch will be immediately followed by another horde
of objectors demanding it be put back the way it was.

zw