fix: preserve Windows target architecture in driver links and resources - #776
Merged
Sunrisepeak merged 4 commits intoOct 6, 2026
Merged
Conversation
Sunrisepeak
added a commit
that referenced
this pull request
Oct 6, 2026
…ing of a target row, windres recognition and the manifest resource's command (#777) - triple::parse writes MSVC's `x86` as `i686`, as `amd64` and `arm64` are written; `[target.x86-windows-msvc]` and `--target x86-windows-msvc` are the i686 row and reach clang and llvm-windres as `i686-pc-windows-msvc` (SPEC-004 1.13 §4.6). - Triple::is_x86_32 and Triple::msvc_arch answer the 32-bit x86 question for the NASM format, the windres COFF target, the MSVC toolset and redist directories, the ABI tool environment and PE export discovery; i386-i586 no longer select the x64 MSVC directory. The 32-bit host_arch is spelled `i686`. - Every reader of a `[target.<triple>]` row finds it by any spelling: find_target_entry moves to mcpp.build.prepare_inputs, and the runner and min_api_level readers use it. - RcTool::llvm is decided by find_rc_tool (the name, or the file a symlink resolves to), so llvm-mingw's `<triple>-windres` receives a triple. - The build program's UTF-8 manifest resource keeps its command beside the object and is compiled again when it changes. - E2E 889 builds the `x86` spelling; unit tests TargetRowSpelling, the triple vocabulary, the MSVC arch mapping, windres recognition and the manifest command. - Docs 04/21 in both languages, SPEC-004 1.13, CHANGELOG (including #775/#776). Design: .agents/docs/2026-10-06-windows-x86-arch-vocabulary-and-rc-follow-ups-design.md
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
An x86 Windows build compiled for i686 but dropped the selected target on the clang driver link. The driver consequently selected the host architecture's CRT. Adding a project link flag worked around that failure, but llvm-windres still produced an x64 COFF resource, which could not link into the x86 image.
Preserve
crossTargetFlagin both C and C++ PE driver links. Select the COFF resource target explicitly: LLVM windres receives the LLVM triple; GNU windres receivespe-i386forx86,i386,i486,i586andi686, orpe-x86-64forx86_64/amd64. Share this selection between planned resources and build-program UTF-8 manifests. Native rc.exe/llvm-rc continue producing architecture-neutral.resfiles.Closes #775.
Criteria
NinjaBackend.WindowsDriverLinksRetainTheSelectedTargetForCAndCxxchecks both driver link lines for i686, x86_64 and aarch64.BuildResources.CoffTargetFollowsTheTargetInsteadOfTheHostchecks LLVM triples, all five 32-bit x86 spellings, GNU BFD names and the unchanged.respath. Both passed locally in the fresh-binary unit suite. The driver-link regression runs on Windows and explicitly skips other hosts, whose links use different branches; the resource-target regression runs in all platform unit-test jobs..rc. It passed locally with the freshly built binary and is selected by the Windows MSVC-capable E2E jobs._mainCRTStartupunresolved). Re-running with only an explicit project link target reached the independent resource failure (res/app.o: machine type x64 conflicts with x86). These establish both pre-fix failures.test: 146 passed, 0 failed on Windows x64, LLVM 20.1.7, MSVC 14.51 and Windows SDK 10.0.26100. Existing Windows resources E2E 197 also passed. Cross-host runtime builds and GNU windres execution are left to CI; they are not claimed as local passes.Intersections
.resneeds no COFF targetCompatibility
No manifest changes or migration are required. Existing x64 builds keep their output architecture; x86 driver builds and resource objects now follow the selected target. Changed Ninja commands rebuild affected resource objects and relink images. Native MSVC link.exe and
.rescompilation are unchanged. GNU windres retains its existing behavior outside the two mapped x86 architectures.Checks before merging
bash .github/tools/check_docs_style.sh,check_docs_structure.shandcheck_version_pins.shpass. Windows Python was run withPYTHONUTF8=1for the structure check.python3 .github/tools/check_workflow_assertions.pypasses (22 workflows, 0 problems). Module wiring, prepare file lengths, narrow-conversion guard andgit diff --checkalso pass.git log origin/main..HEAD -i --grep='Co-Authored-By'prints nothing.fix: preserve Windows target architecture in driver links and resources. Suggested body:Carry the selected target through C/C++ PE driver links and windres COFF compilation. Add unit and real x86/x64 image/resource regression coverage. Closes #775.