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.