From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17421 invoked by alias); 2 Aug 2002 18:01:29 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 17363 invoked from network); 2 Aug 2002 18:01:02 -0000 Received: from unknown (HELO sceaux.ilog.fr) (193.55.64.10) by sources.redhat.com with SMTP; 2 Aug 2002 18:01:02 -0000 Received: from ftp.ilog.fr (ftp.ilog.fr [193.55.64.11]) by sceaux.ilog.fr (8.11.6/8.11.6) with SMTP id g72HvUN11985 for ; Fri, 2 Aug 2002 19:57:40 +0200 (MET DST) Received: from laposte.ilog.fr ([193.55.64.67]) by ftp.ilog.fr (NAVGW 2.5.1.16) with SMTP id M2002080220001831950 ; Fri, 02 Aug 2002 20:00:18 +0200 Received: from honolulu.ilog.fr ([172.17.4.9]) by laposte.ilog.fr (8.11.6/8.11.6) with ESMTP id g72I0GU05518; Fri, 2 Aug 2002 20:00:16 +0200 (MET DST) Received: (from haible@localhost) by honolulu.ilog.fr (8.9.3/8.9.3/SuSE Linux 8.9.3-0.1) id UAA30936; Fri, 2 Aug 2002 20:02:09 +0200 From: Bruno Haible MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15690.51488.507762.707975@honolulu.ilog.fr> Date: Fri, 02 Aug 2002 11:01:00 -0000 To: "John David Anglin" 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 In-Reply-To: <200208021635.g72GZDrs008047@hiauly1.hia.nrc.ca> References: <200208021635.g72GZDrs008047@hiauly1.hia.nrc.ca> <20020801215213.GA16878@kromwill.dtek.chalmers.se> X-SW-Source: 2002-08/txt/msg00094.txt.bz2 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