https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
Nadav Har'El <nyh at math dot technion.ac.il> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nyh at math dot technion.ac.il --- Comment #8 from Nadav Har'El <nyh at math dot technion.ac.il> --- This issue was closed as supposedly it only affects Firefox's build. It definitely does not - it affects any project which attempts to replace the C header files (or just one or few of them) but leave the C++ header files untouched. The latest casualty of the "#include_next" thing is the OSv project (see OSv issue https://github.com/cloudius-systems/osv/issues/768). OSv is a unikernel which replaces glibc with its own C library implementation, including re-implementing all the glibc header files - but it does not replace the libstdc++ header files. Before this "#include_next" thing in the C++ header files, to override the default C header files we just needed to add to the include path OSv's own header directory, and the C header files were picked up from there - while the C++ header files continued to be picked up as usual from their standard location. Now, we can no longer do that, because when the C++ header files try to "#include_next" the C header files, it can't find them, or picks up the wrong one (the standard one from /usr/include). I do have a workaround for this, which includes -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS *and* manually placing another copy of the default C++ header directory in the include path before our replacement C header directory (I've yet to figure out how to find this correctly for any version of gcc...). But it looks really convoluted, and unjustified. I think the correct solution would have been NOT to have the same header file (such as stdlib.h and math.h) in two directories and two projects (libstdc++ and glibc). That duplication caused the mess that the "#include_next" was supposed to fix (and as collateral damage, caused this issue). I believe there is no reason why the C header files (probably in the glibc project) should not be enough for both C and C++ code. If the C++ standard dictates that "stdlib.h" should have something specific for C++, it is quite easy to add that with an #ifdef __cplusplus, and we shouldn't have to require a completely separate file with the same name.