[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[Bug driver/101238] New: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[tomas.kalibera at gmail dot com]

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

            Bug ID: 101238
           Summary: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need
                    -D__USE_MINGW_ACCESS
           Product: gcc
           Version: 10.3.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: driver
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tomas.kalibera at gmail dot com
  Target Milestone: ---

Created attachment 51070
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51070&action=edit
Use -D__USE_MINGW_ACCESS when compiling the driver.

Summary: one needs to add CXXFLAGS+=-D__USE_MINGW_ACCESS to config/mh-mingw so
that the driver finds executables on Windows. This is already fixed in GCC 11,
but not in GCC 10.

More details: GCC 10 driver is compiled with g++ without-D__USE_MINGW_ACCESS on
MinGW. That option is only added to CFLAGS, but not CXXFLAGS. Consequently, the
driver will not find executables such as cc1, because access(,X_OK) will always
return an error on Windows, as access() on Windows does not check for
executability anymore. With __USE_MINGW_ACCESS, MinGW will use its own
implementation of access() which for X_OK behaves the same as R_OK.

I've tested the (trivial) attached patch and it resolved the issue on my system
as expected.

[Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
               Host|                            |mingw

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
Can you please post the patch to gcc-patches@gcc.gnu.org stating how you tested
it?  Also see https://gcc.gnu.org/contribute.html - thanks.

[Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[tomas.kalibera at gmail dot com]

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

--- Comment #2 from Tomas Kalibera <tomas.kalibera at gmail dot com> ---
I started writing that email, but on the way I found that one should add
-D__USE_MINGW_ACCESS also BOOT_CXXFLAGS, which I have neither done nor tested.
The problem I debugged required only required adding to CXXFLAGS.

In principle, one needs to add -D__USE_MINGW_ACCESS everywhere, where GCC might
use "access()" to query X_OK, so it should be safe to add simply everywhere
when compiling C or C++, it just must have been forgotten.

I see -D__USE_MINGW_ACCESS has been added to CXXFLAGS and BOOT_CXXFLAGS in GCC
11 by a patch from Martin Storsjo, "mh-mingw: Set __USE_MINGW_ACCESS in missed
C++ flags variables",
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567815.html

And it is related to "[MinGW] Set __USE_MINGW_ACCESS for C++ as well"
https://gcc.gnu.org/pipermail/gcc-patches/2019-March/518147.html
(done also in GCC 10), which adds __USE_MINGW_ACCESS to STAGE*_CXXFLAGS.

My testing was using an MXE-based build of GCC 10.2 (cross-compiled on Linux,
for 64-bit Windows, with MinGW-w64 7). Without the change, gcc.exe did not find
cc1.exe. Process monitor showed that gcc.exe called stat on cc1.exe
successfully (so used the correct path already the first time), but then
continued checking other locations and when it failed, tried to execute without
path name (relying on system PATH). So a workaround I have been using was to
have also cc1.exe on PATH, where it would be found by Windows (so the problem
of access(,X_OK) did not apply there).

Then the observed behavior matched the code of the driver gcc.c, which calls
access(,X_OK) to check that cc1.exe is executable, and it incorrectly concludes
that it isn't. Which in turn is because access on Windows does not support X_OK
(and __USE_MINGW_ACCESS provides a MinGW replacement which does). I've
confirmed this was what happened via adding print statements to the driver and
rebuilding. And eventually I rebuilt gcc with the proposed patch and it found
cc1.exe fine.

Should I still send a copy of Martin Storsjo's patch to
gcc-patches@gcc.gnu.org, or is this information here now sufficient?

[Bug driver/101238] [9/10 only] backport r11-8147 to gcc-10 and gcc-9: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
            Summary|Driver won't find           |[9/10 only] backport
                   |cc1/cc1plus on MinGW,       |r11-8147 to gcc-10 and
                   |CXXFLAGS need               |gcc-9: Driver won't find
                   |-D__USE_MINGW_ACCESS        |cc1/cc1plus on MinGW,
                   |                            |CXXFLAGS need
                   |                            |-D__USE_MINGW_ACCESS
   Target Milestone|---                         |9.5
   Last reconfirmed|                            |2021-08-16
             Status|UNCONFIRMED                 |NEW

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
.

[Bug driver/101238] [9/10 only] backport r11-8147 to gcc-10 and gcc-9: Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS

[marxin at gcc dot gnu.org]

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

Martin Liška <marxin at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |marxin at gcc dot gnu.org
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #4 from Martin Liška <marxin at gcc dot gnu.org> ---
I've just backported that to both branches as:

g:6fa3bbe854f8a9066c390b802e6a69ef463ede7c
g:9f84f267b166137317f140eae4508b87b20ec485

Let's close it.