This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper
- From: "nyh at math dot technion.ac.il" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 21 Jul 2016 06:13:07 +0000
- Subject: [Bug libstdc++/70722] include_next in cmath skips user-defined wrapper
- Auto-submitted: auto-generated
- References: <bug-70722-4@http.gcc.gnu.org/bugzilla/>
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.