From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10462 invoked by alias); 4 Aug 2002 04:58:43 -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 10453 invoked from network); 4 Aug 2002 04:58:43 -0000 Received: from unknown (HELO crack.them.org) (65.125.64.184) by sources.redhat.com with SMTP; 4 Aug 2002 04:58:43 -0000 Received: from dsl254-114-118.nyc1.dsl.speakeasy.net ([216.254.114.118] helo=nevyn.them.org ident=mail) by crack.them.org with asmtp (Exim 3.12 #1 (Debian)) id 17bDTa-0004Wy-00 for ; Sat, 03 Aug 2002 23:58:46 -0500 Received: from drow by nevyn.them.org with local (Exim 3.35 #1 (Debian)) id 17bDTi-0002Vl-00 for ; Sun, 04 Aug 2002 00:58:54 -0400 Date: Sat, 03 Aug 2002 21:58:00 -0000 From: Daniel Jacobowitz To: gcc@gcc.gnu.org Subject: Re: gcc 3.2's cpp breaks configure scripts Message-ID: <20020804045853.GA9519@nevyn.them.org> Mail-Followup-To: gcc@gcc.gnu.org References: <200208022142.g72LgWY12317@green.twinsun.com> <200208032142.g73LgBE6003287@hiauly1.hia.nrc.ca> <20020803230707.GG466@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020803230707.GG466@codesourcery.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2002-08/txt/msg00169.txt.bz2 On Sat, Aug 03, 2002 at 04:07:07PM -0700, Zack Weinberg wrote: > I do not see how this follows. The problems caused by > -I 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? Somewhat tangential to the current discussion, but I was referring specifically to /usr/include and /usr/local/include, not to any sort of ${prefix}/include (which I always disable in our toolchains anyway; for historical reasons our ${prefix}/include is where things like the cross BFD's headers go, not where target headers go. But that's just a quirk of our environment. > 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. Absolutely agreed. -- Daniel Jacobowitz Carnegie Mellon University MontaVista Software Debian GNU/Linux Developer