[Bug target/105506] Error building GCC 12.1.0 against MinGW-w64: fatal error: cannot execute 'cc1': CreateProcess: No such file or directory

["martin at martin dot st" <gcc-bugzilla@gcc.gnu.org>]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105506

Martin Storsjö <martin at martin dot st> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin at martin dot st

--- Comment #6 from Martin Storsjö <martin at martin dot st> ---
This is an old longstanding issue that seems to have reappeared, but which has
been fixed differently recently in the very latest mingw-w64 git. But first a
brief history of the issue:

GCC uses the access() function for checking whether a binary exists and is
executable (with the X_OK flag as parameter). On Windows, there's no separate
"execute" permission bit, but the X_OK bit (which isn't a documented parameter
from Microsoft's side) used to be ignored.

In Vista, msvcrt.dll's access() function suddenly stopped ignoring the bit that
was used for X_OK (which mingw had decided to use for that purpose), and
started erroring out when this bit was set. This was dealt with in 2007 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33281, by adding a
reimplementation of the access() function in mingw. By defining
__USE_MINGW_ACCESS, the access() function is redirected to the __mingw_access()
function. GCC set -D__USE_MINGW_ACCESS when building on mingw to include this
workaround.

After some time, it seems like Microsoft reverted this behaviour in
msvcrt.dll's access() function, because now it no longer seems like this
behaviour is present, not on modern Windows 10, but not even on "modern"
installations of Vista either. So the need for -D__USE_MINGW_ACCESS has
vanished (and bitrotted in GCC somewhat).

UCRT's access() function does have the same issue though - if passed the
undocumented, mingw-invented X_OK bit, it errors out. As GCC did try to define
__USE_MINGW_ACCESS, the workaround should have been picked up though, but as
GCC's codebase had evolved, the define wasn't being set in all the cases where
it might have been needed. This was fixed for GCC 11 in
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=89e95ad2e7679322b2f5ee9070ff2721d5ca1d6d
(and later backported to GCC 9 and 10 in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101238).

But apparently something has changed further in GCC 12, so that this define
doesn't end up set in all the places where it needs to. (It'd be interesting to
know why/where/when!) In mingw-w64, we decided to enable this workaround
unconditionally for UCRT (as a more general fix for other audiences, although
GCC is the only one I've heard of needing it) - skipping the UCRT provided
access() function and always using the mingw reimplementation, see
https://github.com/mingw-w64/mingw-w64/commit/bceadc54d8f32b3f14c69074892e2718eac08e3b.

So to successfully build GCC 12 running on UCRT, you'd need to use another GCC
install, with the very latest mingw-w64 (or an older release with that fix
cherry-picked, plus the following Makefile.in update from
https://github.com/mingw-w64/mingw-w64/commit/89bacd2be60fa92dd74d3b5f2074b06a32d8c784),
to build GCC 12. Alternatively, see if you can manually pass
-D__USE_MINGW_ACCESS to the GCC 12 build, if it'd end up in all the places
where it's needed.