https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100017
Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2021-04-21 Ever confirmed|0 |1 --- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> --- The target build is finding the host libstdc++'s <fenv.h> which has the same _GLIBCXX_FENV_H include guard, so when the target <fenv.h> does: #include_next <fenv.h> it doesn't do anything. It might be necessary to do something simialr to what's in <cstdlib>: // Need to ensure this finds the C library's <stdlib.h> not a libstdc++ // wrapper that might already be installed later in the include search path. #define _GLIBCXX_INCLUDE_NEXT_C_HEADERS #include_next <stdlib.h> #undef _GLIBCXX_INCLUDE_NEXT_C_HEADERS where the libstdc++ <stdlib.h> wrapper does: #if !defined __cplusplus || defined _GLIBCXX_INCLUDE_NEXT_C_HEADERS # include_next <stdlib.h> #else #ifndef _GLIBCXX_STDLIB_H #define _GLIBCXX_STDLIB_H 1 That ensures that we eventually reach the libc <stdlib.h> and not just another libstdc++ wrapper.