https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103011
Pekka S <p...@gcc-bugzilla.mail.kapsi.fi> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |p...@gcc-bugzilla.mail.kaps
| |i.fi
--- Comment #7 from Pekka S <p...@gcc-bugzilla.mail.kapsi.fi> ---
I have a similar cross compiler setup and I'm seeing this exact issue.
However, I suspect this is actually due to
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=84401ce5fb4ecab55decb472b168100e7593e01f.
Looking at `gcc/build-x86_64-linux-gnu/libiberty/config.log'
libiberty/configure uses different compiler/preprocessor for tests;
ac_fn_c_try_compile uses `gcc' (i.e. host) but ac_fn_c_try_cpp (via
ac_fn_c_check_header_preproc, the one which is used for e.g. process.h probing)
uses `x86_64-w64-mingw32-gcc -E' (i.e. target).
This can be also seen from the corresponding
`gcc/build-x86_64-linux-gnu/libiberty/config.cache' where ac_cv_env_CPP_value
and ac_cv_prog_CPP are populated with target preprocessor whereas other are
host programs.
I presume this shouldn't happen since `gcc/build-x86_64-linux-gnu/libiberty' is
being built (its target counterpart `gcc/libiberty' compiles just fine).
