[PATCH] Prevent GCC 6 <cstdlib> from including /usr/include/stdlib.h

[Florian Weimer]

On 06/11/2016 12:07 AM, Roland McGrath wrote:
> In what way is it not a bug for cstdlib to do #include_next <stdlib.h>?

They are part of the implement in the same way we are.  Why would it be 
a bug?

> The only purpose I understand for using #include_next is when a header
> named foo does #include_next <foo>.

I think it ignores the search path entries up to and including the 
search path entry the current header file was found.  But I could not 
find documentation for it.

There is a need to wrap around glibc headers (do some stuff before and 
after <stdlib.h> and other headers are included) to get support for some 
C++ functionality, in addition to other header file coordination work.

It's not that we do point releases to add C++ support to our headers, so 
I can see why GCC is doing this.

> If it really is somehow proper for
> cstdlib to be demanding that it get a stdlib.h from an include directory
> later in the include path than is the directory containing that cstdlib,
> then the proper fix is to change our C++ compilations to put the standard
> C++ include directories earlier in the path than the libc source
> directories that are performing the function of system C include directories.

Yes, this is what Carlos meant with the sysroot reference.  I don't 
think we actually need support for that in the toolchain (and I'm not 
sure if it's actually workable without a “create a new sysroot” program, 
which does not exist AFAIK).  We need to prepare a single directory 
which contains all the installed headers, plus symbolic links to the 
kernel/Mach imports.  Then we get the standard include path from GCC, 
replace /usr/include with this directory, and instruct gcc/g++ to use 
exactly those include search paths.

Do you think this might work?

This would only be used for compiling the tests (both C and C++).  As 
far as I know, we do not have any C++ code in the library proper.  It 
will need changing some of the tests not to use internal interfaces, and 
some special support for whitebox testing.

Thanks,
Florian