This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/70722] include_next in cmath skips user-defined wrapper


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]