From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21009 invoked by alias); 1 Aug 2002 21:52:21 -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 20652 invoked from network); 1 Aug 2002 21:52:14 -0000 Received: from unknown (HELO mail.dtek.chalmers.se) (129.16.30.197) by sources.redhat.com with SMTP; 1 Aug 2002 21:52:14 -0000 Received: from kromwill.dtek.chalmers.se (kromwill.dtek.chalmers.se [129.16.30.52]) by mail.dtek.chalmers.se (Postfix) with ESMTP id D0B3A3B21B; Thu, 1 Aug 2002 23:52:13 +0200 (MEST) Received: (from d95hjort@localhost) by kromwill.dtek.chalmers.se (8.9.3/8.9.3) id XAA19683; Thu, 1 Aug 2002 23:52:13 +0200 (MEST) Date: Thu, 01 Aug 2002 14:52:00 -0000 From: H}kan Hjort To: John David Anglin Cc: gcc@gcc.gnu.org Subject: Re: gcc 3.2's cpp breaks configure scripts Message-ID: <20020801215213.GA16878@kromwill.dtek.chalmers.se> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit User-Agent: Mutt/1.3.25i X-SW-Source: 2002-08/txt/msg00047.txt.bz2 John David Anglin wrote: > The gcc warning is correct in the cases that I have examined. I don't > believe that configure should be adding include directories to CPPFLAGS > that are already being searched as system directories by gcc. This > changes the include search order as noted in the warning and may > cause unexpected results. > Ah but which are theses directories? There is no way to know as far as I can see. (If you don't fancy doing some rather serious parsing of either the specfile, the output from -dumpspecs or from gcc -v -E). Since some thimes for example /usr/local/include will be a system directory and some times not. [snip] > There may be some debate as to what directories gcc should treat > as "system" directories. However, configure shouldn't change > the default search order of gcc without good reason, irrespective > of whether the directories are truly system directories or not. > this affects gcc's mechanism to fix headers. Ehh.. not everyone installs every pice of software out there in /usr so then you need to tell configure where to find the stuff, and it in turn needs to add the -I and -L / -R flags. Now if user says that 'oh I have libjpeg installed in /usr/local', should I then add -I/usr/local/include to CPPFLAGS or not? If I do so on a standard Linux system it will fail becuse of: cpp0: warning: changing search order for system directory "/usr/local/include" cpp0: warning: as it has already been specified as a non-system directory on the other hand if I don't then on a FreeBSD system it will fail with: conftest.c:4:17: jpeglib.h: No such file or directory [snip] > Possibly, if gcc provided a simpler way to print the search order, > the autoconf macro authors could be persuaded not to append these > directories to CPPFLAGS. The reasons to do this are documented. > Turning the warning off is not the correct solution, although there > may be some circumstances in which it is emitted when it shouldn't > be. Or if there where autoconf macros that handled all of this instead of each package having the code to let users specify if/where a dependecy can be found. Then trying to work out if the path must or must _not_ be added. The fact that there still are many configure scripts out there that now fail just because of this, still stands. The only way to turn of this warning is with -w 'Inhibit warning messages'. I don't know if adding that to CPPFLAGS will cause any other averse affects. -- Håkan Hjort