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.