This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Prevent GCC 6 <cstdlib> from including /usr/include/stdlib.h
- From: Florian Weimer <fweimer at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Andreas Schwab <schwab at suse dot de>, libc-alpha at sourceware dot org
- Date: Sat, 11 Jun 2016 11:41:53 +0200
- Subject: Re: [PATCH] Prevent GCC 6 <cstdlib> from including /usr/include/stdlib.h
- Authentication-results: sourceware.org; auth=none
- References: <20160608150824 dot C6B3A4012D197 at oldenburg dot str dot redhat dot com> <mvma8iv66k7 dot fsf at hawking dot suse dot de> <66891e52-9d31-9c8e-02f8-ee068d041184 at redhat dot com> <20160610220726 dot 98FE62C39F7 at topped-with-meat dot com>
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