From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 1FD71394D8AA; Tue, 29 Jun 2021 08:26:01 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1FD71394D8AA From: "tomas.kalibera at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug driver/101238] Driver won't find cc1/cc1plus on MinGW, CXXFLAGS need -D__USE_MINGW_ACCESS Date: Tue, 29 Jun 2021 08:26:00 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: driver X-Bugzilla-Version: 10.3.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: tomas.kalibera at gmail dot com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Jun 2021 08:26:01 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D101238 --- Comment #2 from Tomas Kalibera --- 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 test= ed. The problem I debugged required only required adding to CXXFLAGS. In principle, one needs to add -D__USE_MINGW_ACCESS everywhere, where GCC m= ight 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 mis= sed 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 Linu= x, 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 wit= hout 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 probl= em 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 concl= udes 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 fou= nd 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?=