From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17747 invoked by alias); 2 Aug 2002 19:29:37 -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 17738 invoked from network); 2 Aug 2002 19:29:34 -0000 Received: from unknown (HELO hiauly1.hia.nrc.ca) (132.246.100.193) by sources.redhat.com with SMTP; 2 Aug 2002 19:29:34 -0000 Received: from hiauly1.hia.nrc.ca (localhost [127.0.0.1]) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) with ESMTP id g72JTU00009493; Fri, 2 Aug 2002 15:29:31 -0400 (EDT) Received: (from dave@localhost) by hiauly1.hia.nrc.ca (8.12.0.Beta16/8.12.0.Beta16) id g72JTU7Q009491; Fri, 2 Aug 2002 15:29:30 -0400 (EDT) Message-Id: <200208021929.g72JTU7Q009491@hiauly1.hia.nrc.ca> Subject: Re: gcc 3.2's cpp breaks configure scripts To: haible@ilog.fr (Bruno Haible) Date: Fri, 02 Aug 2002 12:29:00 -0000 From: "John David Anglin" Cc: bug-gnu-gettext@gnu.org, bug-textutils@gnu.org, gcc@gcc.gnu.org, meyering@lucent.com In-Reply-To: <15690.51488.507762.707975@honolulu.ilog.fr> from "Bruno Haible" at Aug 2, 2002 08:02:08 pm MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-SW-Source: 2002-08/txt/msg00098.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. Which cases are these? Irrespective of whether or not the directory is truly a "system" directory, the patch detects directories that gcc will search. A "-I" is unnecessary for these directories unless you actually want to change the search order. This is dangerous unless you have intimate knowledge of how the system is configured. Gcc has a predefined search order for its "system" directories and I have yet to see a convincing reason why its necessary to change this order for building packages which use the gettext macros. The only situation where I can see a problem is when a header is installed in two of the directories searched automatically by gcc and the user attempts to select the one that is searched second. With my patch, you will get the header in the first directory rather than the one in the second directory and this could cause a problem due to inconsistent versions. I would prefer configure checked for this than give up the predefined search order. As noted in previous mail, gcc searches both /usr/local/include and /opt/gnu/include when it is configured with /opt/gnu, so if you add -I/opt/gnu the search order of the two directories is changed. This may cause different headers to be used and cause unexpected results for other headers depending on how the system is configured. > 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. Yes, that's a valid point. In the case at hand, none of the above were installed in a fixincludes directory. The main point of debate is whether or not the search order of non-fixinclude include directories should by changeable without a warning. Personally, I think it's a mugs game to try rearrange the header search order to select a specific set of headers. > > 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. Agreed. However, I think we have to live with the fixinclude scheme and the fact that gcc has a set of include directories that it searches in a predefined order. Dave -- J. David Anglin dave.anglin@nrc.ca National Research Council of Canada (613) 990-0752 (FAX: 952-6605)