Repository navigation
E2E toolchain helper exports GCC_ROOT and redirects cold MinGW and musl driver helpers #783
Description
Activity
- added a commit that references this issue
on Oct 7, 2026 Follow-up evidence from CI run 37686310140, bare-Windows job 113022802077 changes the strength of the earlier infrastructure attribution.
The downloaded mingw-gcc 16.1.0 archive matches the index SHA256. Its g++.exe is GCC 16.1.0 (SHA256 e0fe91a127f5c7b8c161bf66109818a40a9ca93be94d744a3c1686946a8f63d0), and its cc1plus.exe SHA256 matches the cold installed helper. However, the cold driver search report names GCC 15.2.0, C:/mingw64, and the global mcpp registry. This is inconsistent with the intended cold 16.1.0 payload.
A runner-image change and the existence of cc1plus.exe do not establish Defender as the root cause. PR #781 now captures the executed driver hash/version/PE, environment variable names without assuming case, same-byte renamed-driver results, and a native PowerShell launch comparison. These distinguish payload changes, process routing and environment contamination before choosing a fix.
The issue remains open. Final-head CI and the Windows regression must pass before closing it. Evidence: https://github.com/mcpp-community/mcpp/actions/runs/37686310140/job/113022802077 ; diagnostic changes: bed4876.
Correction to the previous driver-search interpretation: the diagnostic loop enumerated both the real payload g++.exe and the registry SubOS g++.exe shim, and overwrote the single report files on its second iteration. The GCC 15.2.0/global search output therefore belongs to shim dispatch, not to the payload executable. Both the previous and current file listings contain these two executables.
The new failure artifacts prove the actual cold payload g++.exe SHA256 is e0fe91a127f5c7b8c161bf66109818a40a9ca93be94d744a3c1686946a8f63d0, exactly matching the verified GCC 16.1.0 archive. cc1plus.exe also matches. There is currently no proof that the payload driver is the wrong version, and no established Defender cause.
The next diagnostic revision separates payload and shim reports and directly compiles a small source with cc1plus. A silent successful cc1plus --version alone is not a functional compile test. The real compiler/helper launch failure remains open. New evidence: https://github.com/mcpp-community/mcpp/actions/runs/37690944669/job/113037550294 .
The new raw-payload diagnostics identify a test environment regression rather than a missing GCC archive or a path-form failure.
On head 9229b97, the genuine GCC 16.1.0 driver matches the published archive SHA, and direct cc1plus compilation succeeds and produces assembly. Raw-driver/MSYS, native PowerShell canonical paths, and native PowerShell 8.3 paths fail identically. The driver install prefix belongs to the isolated payload, but its program search prefix points to the global ~/.mcpp generic GCC directory, which does not contain the isolated payload helpers.
The version abstraction introduced in this PR exports GCC_ROOT from tests/e2e/_toolchain_env.sh. GCC interprets that name as its own prefix control: https://github.com/gcc-mirror/gcc/blob/master/gcc/prefix.cc. Because the helper is sourced before a cold MCPP_HOME is created, the exported outer-home path redirects the later compiler. A real GCC control experiment reproduces the same cc1plus posix_spawnp failure with an exported nonexistent GCC_ROOT; the clean control resolves the helper and compiles successfully. The native ARM64 musl regression has the same inherited variable and is being verified independently.
The fix renames the fixture variable to MCPP_E2E_GCC_ROOT, preserving genuine user GCC_ROOT configuration. No compiler asset replacement or Defender exclusion is justified. The Windows-image/Defender attribution is withdrawn. This issue remains open until the corrected final-head bare-Windows job actually passes.
- changed the title
[-]bare-Windows leg: mingw-gcc 16.1.0 cc1plus.exe cannot execute on the new windows-latest image (win22/20261004.326.1); green on win25-vs2026/20260925.250[/-][+]E2E toolchain helper exports GCC_ROOT and redirects cold MinGW and musl driver helpers[/+]on Oct 7, 2026 - added a commit that references this issue
on Oct 9, 2026
The E2E toolchain-version helper exported
GCC_ROOTas an outer-registry path. GCC relocation builds interpret that variable as a compiler prefix control. After E2E 182 creates a coldMCPP_HOME, the real MinGW 16.1.0 driver therefore searches the outer generic GCC installation forcc1plusrather than its own payload. Native ARM64 musl GCC hit the same pollution.The previous Windows-image/Defender attribution is withdrawn. The driver and
cc1plusdigests match the indexed archive; directcc1pluscompilation succeeds. Native PowerShell, MSYS, long paths, and complete 8.3 paths showed the same redirected helper prefix. Separate real GCC clean/bad-prefix controls reproduce and remove the failure.PR #781 renames the fixture path to
MCPP_E2E_GCC_ROOT, preserves genuine userGCC_ROOT, and adds real compiler/environment regressions to CI. No engine lookup, payload bytes, image, or Defender configuration changes are required.Validation on corrected commit
553861c4:Final-head CI and merge of #781 remain required. This issue tracks the helper regression and closes with that PR; it provides no infrastructure exemption for a failing CI leg. Earlier comments retain the investigation history and its explicit corrections.