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.

Reply via email to