From: Zack Weinberg <zack@codesourcery.com>
To: John David Anglin <dave@hiauly1.hia.nrc.ca>
Cc: Paul Eggert <eggert@twinsun.com>,
haible@ilog.fr, bug-gnu-gettext@gnu.org, bug-textutils@gnu.org,
gcc@gcc.gnu.org, meyering@lucent.com,
Nathan Sidwell <nathan@codesourcery.com>
Subject: Re: gcc 3.2's cpp breaks configure scripts
Date: Sat, 03 Aug 2002 16:07:00 -0000 [thread overview]
Message-ID: <20020803230707.GG466@codesourcery.com> (raw)
In-Reply-To: <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
next prev parent reply other threads:[~2002-08-03 23:07 UTC|newest]
Thread overview: 40+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200208021635.g72GZDrs008047@hiauly1.hia.nrc.ca>
2002-08-01 14:52 ` H}kan Hjort
2002-08-01 20:09 ` John David Anglin
2002-08-02 11:01 ` Bruno Haible
2002-08-02 12:29 ` John David Anglin
2002-08-02 14:42 ` Paul Eggert
2002-08-03 13:48 ` Nix
2002-08-03 14:55 ` John David Anglin
2002-08-03 15:24 ` Zack Weinberg
2002-08-03 19:34 ` Gareth Pearce
2002-08-03 14:42 ` John David Anglin
2002-08-03 15:36 ` Gabriel Dos Reis
2002-08-03 16:07 ` Zack Weinberg [this message]
2002-08-03 20:33 ` John David Anglin
2002-08-03 21:58 ` Miles Bader
2002-08-03 21:58 ` Daniel Jacobowitz
2002-08-11 10:27 John David Anglin
2002-08-12 14:40 ` Nix
-- strict thread matches above, loose matches on Subject: below --
2002-08-01 16:54 Gareth Pearce
[not found] <no.id>
2002-08-01 12:02 ` John David Anglin
2002-08-01 0:15 Gareth Pearce
2002-08-01 0:35 ` Jakub Jelinek
2002-08-01 0:03 Gareth Pearce
2002-08-01 0:07 ` Jakub Jelinek
2002-07-31 23:52 Gareth Pearce
2002-07-31 8:58 Jeff Garzik
2002-07-31 9:07 ` Gareth Pearce
2002-07-31 12:44 ` Joe Buck
2002-08-01 10:32 ` Phil Edwards
2002-08-01 11:15 ` Neil Booth
2002-08-01 12:31 ` Phil Edwards
2002-07-31 9:19 ` Andreas Schwab
2002-07-31 9:39 ` Jeff Garzik
2002-07-31 9:39 ` Jan-Benedict Glaw
2002-07-31 9:54 ` Michael Matz
2002-08-01 9:45 ` Kai Henningsen
2002-08-01 12:40 ` Kevin Handy
2002-08-01 9:45 ` Kai Henningsen
2002-08-01 14:47 ` Joe Buck
2002-08-08 20:39 ` Roger Corman
2002-08-09 12:07 ` Joe Buck
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20020803230707.GG466@codesourcery.com \
--to=zack@codesourcery.com \
--cc=bug-gnu-gettext@gnu.org \
--cc=bug-textutils@gnu.org \
--cc=dave@hiauly1.hia.nrc.ca \
--cc=eggert@twinsun.com \
--cc=gcc@gcc.gnu.org \
--cc=haible@ilog.fr \
--cc=meyering@lucent.com \
--cc=nathan@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).