From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9380 invoked by alias); 2 Aug 2002 21:42:38 -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 9266 invoked from network); 2 Aug 2002 21:42:34 -0000 Received: from unknown (HELO alcor.twinsun.com) (198.147.65.9) by sources.redhat.com with SMTP; 2 Aug 2002 21:42:34 -0000 Received: from green.twinsun.com ([192.54.239.71]) by alcor.twinsun.com (8.12.1/8.12.1) with ESMTP id g72LgWgt011664; Fri, 2 Aug 2002 14:42:33 -0700 (PDT) Received: (from eggert@localhost) by green.twinsun.com (8.11.6+Sun/8.11.6) id g72LgWY12317; Fri, 2 Aug 2002 14:42:32 -0700 (PDT) Date: Fri, 02 Aug 2002 14:42:00 -0000 From: Paul Eggert Message-Id: <200208022142.g72LgWY12317@green.twinsun.com> To: dave@hiauly1.hia.nrc.ca CC: haible@ilog.fr, bug-gnu-gettext@gnu.org, bug-textutils@gnu.org, gcc@gcc.gnu.org, meyering@lucent.com In-reply-to: <200208021929.g72JTU7Q009491@hiauly1.hia.nrc.ca> (dave@hiauly1.hia.nrc.ca) Subject: Re: gcc 3.2's cpp breaks configure scripts References: <200208021929.g72JTU7Q009491@hiauly1.hia.nrc.ca> X-SW-Source: 2002-08/txt/msg00106.txt.bz2 > From: "John David Anglin" > Date: Fri, 2 Aug 2002 15:29:29 -0400 (EDT) > > 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. But GCC warns in many cases where there is no problem. It is crying wolf far too often in practice. People are learning to ignore those warnings. I am considering putting a sed filter around GCC to remove these warnings entirely. But, more likely, I will install GCC in a nonstandard place, so that it doesn't include my local equivalent of /opt/gnu/include by default. I think that's what Bruno's sysadmin does. It is an ugly solution (e.g., it means I'll see "-I/opt/gnu/include" a lot), but it beats dealing with this hassle all the time. If GCC warned only when there was a real problem, a lot of these issues would go away. > 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. In all the cases where I've seen this warning, the header search order did not matter, and the files behaved identically in "user" and "system" mode, so GCC's warning was inappropriate. > > > 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 No, we could fix system includes files on every run of GCC, for example. In the old days that would have been impractical for performance reasons, but nowadays the hassle of dealing with this problem outweighs any minor slowdowns that would accrue from fixing system include files dynamically. There are other possible solutions too, basically building on the __STDC__ idea that GCC already uses. This problem is becoming a major inconvenience in using GCC, and it would be nice if someone would fix it.