Re: Dejagnu: use -isystem to include system header files.

[Richard Earnshaw <rearnsha@gcc.gnu.org>]

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
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 <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.

R.