public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bruno Haible <haible@ilog.fr>
To: "John David Anglin" <dave@hiauly1.hia.nrc.ca>
Cc: bug-gnu-gettext@gnu.org, bug-textutils@gnu.org, gcc@gcc.gnu.org,
	meyering@lucent.com
Subject: Re: gcc 3.2's cpp breaks configure scripts
Date: Fri, 02 Aug 2002 11:01:00 -0000	[thread overview]
Message-ID: <15690.51488.507762.707975@honolulu.ilog.fr> (raw)
In-Reply-To: <200208021635.g72GZDrs008047@hiauly1.hia.nrc.ca>

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.

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.

If the added directory is not a fixincluded one, then there is no
reason for GCC warning - except for Jakub's arguments.

Jakub Jelinek writes:

> > you're saying that adding -I/usr/include (or similar) can cause libstdc++ 
> > headers to break due to the way they use #include_next?
> Yes.

Then indeed it would be wrong to add -Idir to the command line. But
then also, you should document in the GCC documentation that users
should not install packages in these directories. Because any freshly
installed .h file in such a directory may be hidden by the ones in
gcc's private gcc-lib/platform/version/include directory, which are
older but have not been updated.

In this case, it'd be best for autoconf macro authors if gcc provided
an easy to use, documented way to test whether a directory is
forbidden for -I or not. I'd then use this test in two situations:
  1) When searching for a library and its include files, this
     directory shall be skipped, even if it equals $prefix/include,
  2) When installing a library, configure will refuse to install in
     such a forbidden directory.

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

Bruno

  parent reply	other threads:[~2002-08-02 18:01 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 [this message]
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
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=15690.51488.507762.707975@honolulu.ilog.fr \
    --to=haible@ilog.fr \
    --cc=bug-gnu-gettext@gnu.org \
    --cc=bug-textutils@gnu.org \
    --cc=dave@hiauly1.hia.nrc.ca \
    --cc=gcc@gcc.gnu.org \
    --cc=meyering@lucent.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).