This is the mail archive of the
mailing list for the binutils project.
Re: Dejagnu: use -isystem to include system header files.
- From: Richard Earnshaw <rearnsha at gcc dot gnu dot org>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sources dot redhat dot com, gdb-patches at sources dot redhat dot com, newlib at sources dot redhat dot com
- Date: Thu, 18 Nov 2004 11:15:05 +0000
- Subject: Re: Dejagnu: use -isystem to include system header files.
- Organization: GNU
- References: <firstname.lastname@example.org> <419C6925.email@example.com>
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 <limits.h> 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 <stdio.h> rather than <limits.h> 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
> 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 <limits.h> 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.