This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc 3.2's cpp breaks configure scripts
- From: Zack Weinberg <zack at codesourcery dot com>
- To: John David Anglin <dave at hiauly1 dot hia dot nrc dot ca>
- Cc: Paul Eggert <eggert at twinsun dot com>, haible at ilog dot fr,bug-gnu-gettext at gnu dot org, bug-textutils at gnu dot org, gcc at gcc dot gnu dot org,meyering at lucent dot com, Nathan Sidwell <nathan at codesourcery dot com>
- Date: Sat, 3 Aug 2002 16:07:07 -0700
- Subject: Re: gcc 3.2's cpp breaks configure scripts
- References: <200208022142.g72LgWY12317@green.twinsun.com> <200208032142.g73LgBE6003287@hiauly1.hia.nrc.ca>
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