This is the mail archive of the
mailing list for the binutils project.
Re: Dejagnu: use -isystem to include system header files.
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
I have confirmed that using <stdio.h> in place of <limits.h> does fix
the unexpected failures.
Is there actually a general problem ? The issue seems to be which
version of <limits.h> is included by a test case using the dejagnu test
harness. If we include the newlib version then tests that use strict
ANSI parsing will fail. If we include the version in the gcc build
directory then tests that assume that <limits.h> has come from newlib
It seems to me that using -isystem to include header files in the newlib
include directories is the correct thing to do. They are system header
files after all. Assuming that you can determine whether you are going
to link with a C-library created by newlib by #include'ing <limits.h>
seems dodgy to me. Using <stdio.h> instead of <limits.h> is a
workaround, but really the testcases ought to provide some weak aliases
for the missing functions and then the _NEWLIB_VERSION check would be
unnecessary. (It would limit the tests to only being run by targets
which support weak aliases but I do not consider this to be a serious
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.
But - how would this help in the situation where -ansi and -pedantic
have been specified as well. In those cases we do not want to get the
limits.h file from newlib.