From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15191 invoked by alias); 18 Nov 2004 11:15:34 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 15113 invoked from network); 18 Nov 2004 11:15:19 -0000 Received: from unknown (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org with SMTP; 18 Nov 2004 11:15:19 -0000 Received: from pc960.cambridge.arm.com (pc960.cambridge.arm.com [10.1.205.4]) by cam-admin0.cambridge.arm.com (8.12.10/8.12.10) with ESMTP id iAIBENso028010; Thu, 18 Nov 2004 11:14:23 GMT Received: from pc960.cambridge.arm.com (localhost.localdomain [127.0.0.1]) by pc960.cambridge.arm.com (8.12.8/8.12.8) with ESMTP id iAIBF5gK024843; Thu, 18 Nov 2004 11:15:05 GMT Received: (from rearnsha@localhost) by pc960.cambridge.arm.com (8.12.8/8.12.8/Submit) id iAIBF5UN024841; Thu, 18 Nov 2004 11:15:05 GMT X-Authentication-Warning: pc960.cambridge.arm.com: rearnsha set sender to rearnsha@gcc.gnu.org using -f Subject: Re: Dejagnu: use -isystem to include system header files. From: Richard Earnshaw To: Nick Clifton Cc: binutils@sources.redhat.com, gdb-patches@sources.redhat.com, newlib@sources.redhat.com In-Reply-To: <419C6925.8010007@redhat.com> References: <1100713585.23221.6.camel@pc960.cambridge.arm.com> <419C6925.8010007@redhat.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: GNU Message-Id: <1100776504.23221.47.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Thu, 18 Nov 2004 11:15:00 -0000 X-SW-Source: 2004-11/txt/msg00371.txt.bz2 On Thu, 2004-11-18 at 09:19, Nick Clifton wrote: > Hi Richard, > > > Nick Clifton wrote: > > I am going to check in the attached patch which imports a fix from > > the mainline dejagnu sources. This fix is to use the -isystem > > switch to include system header files rather than -I. This fixes > > several unexpected failures in the GCC and G++ testsuites where the > > newlib system header file is included in strict ANSI > > mode, and the compiler barfs on the #include_next directive. > > > > Unfortunately this patch causes regressions on the gcc builtins tests. > > These tests rely on detecting newlib by looking for the definition of > > _NEWLIB_VERSION being added by including limits.h; but the change in the > > search order means that we now pick up a dummy version of newlib.h from > > the gcc include directory. > > > > With your patch the search path has now become > > > > /work/rearnsha/gnu/egcs/gcc/include > > /work/rearnsha/gnu/egcs/arm-elf/./newlib/targ-include > > /home/rearnsha/gnusrc/egcs-cross/newlib/libc/include > > > > Whereas previously the gcc/include directory came later in the search. > > Hmmm, maybe newlib could provide the "l" variants of the builtin > functions ? What are these functions anyway ? Long double. I'm not sure if newlib wants to go that way, but if it does it's probably a fair amount of work, especially since long double means different things on different targets. > > Or maybe > builtins-config.h could include say rather than so > that it would pickup the newlib version and not the gcc version ? > That might be OK for this case, but I'm not sure if will solve the problem generally. > Alternatively - can you think of another way of solving the problem that > my patch was originally fixing ? Namely that several GCC and G++ tests > fail because they include whilst in strict ANSI mode and this > fails because the newlib limits.h uses the GNU extension #include_next > directive. My first patch to solve this - by undefining __GNUC__ if > __STRICT_ANSI__ was defined was rejected on the gcc lists. I think the gcc/include directory must be added implicitly from the -B option. It would appear that these add -isystem type include directories, so it might be just a matter of ordering the -B and -isystem options appropriately. R.