https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70722
--- Comment #10 from Nadav Har'El <nyh at math dot technion.ac.il> --- There is nothing "holy" about glibc, and nothing "broken" about wanting to replace it (or, as Firefox did, only a part of it). Sure, the replacement needs to be 100% compatible with glibc, and if it isn't, the replacement needs to be fixed (e.g., I just fixed this https://github.com/cloudius-systems/osv/issues/770 and didn't come complaining to the libstdc++ project). HOWEVER, in this case, the projects in question (Firefox, OSv, and probably more to come) did nothing incorrect or incompatible in their glibc replacement. Their only "sin" was the order of the header files. Moreover, playing with the order is not enough to fix this mess. The problem is that on one hand we need the replacement C library headers to come *after* the C++ headers (because of the #include_next thing in the C++ headers) but on the other hand when we do include "stdlib.h" we need it to come from the replacement C library, NOT from the C++ library, requiring the opposite path order! Luckily, the -D_GLIBCXX_INCLUDE_NEXT_C_HEADERS trick solves that issue. So it's not impossible to solve, it's just really awkward, and the awkwardness suggests that it was the wrong solution to have two copies of the same header file with "#include_next" as a trick to have one include the others. I still don't understand why the glibc header files could not have been improved to accommodate also the C++ standard (and I have no idea what the issues were) instead of needing to have copies of the same header file in both libstdc++ and glibc.
