Set windres target explicitly to better support LLVM cross-compilation#33
Merged
BenjaminRi merged 1 commit intoBenjaminRi:masterfrom Jul 13, 2025
AlexTMjugador:fix/explicit-windres-target
Merged
Set windres target explicitly to better support LLVM cross-compilation#33BenjaminRi merged 1 commit intoBenjaminRi:masterfrom AlexTMjugador:fix/explicit-windres-target
windres target explicitly to better support LLVM cross-compilation#33BenjaminRi merged 1 commit intoBenjaminRi:masterfrom
AlexTMjugador:fix/explicit-windres-target
Conversation
[As stated on its man page](https://man7.org/linux/man-pages/man1/windres.1.html), `windres` uses a default binutils`BFD format when the `--target` option is not explicitly set. This usually works fine with the binutils `windres` implementation even in cross-compilation scenarios, as these have to be set up with a toolchain that's already wired to produce objects for the desired target architecture. However, the LLVM toolchain ships with a `windres` implementation that has a significant behavioral difference in this regard: LLVM is a native cross-platform compiler, which means that no separate toolchains are needed to target a different platform. As such, [LLVM's `windres` defaults to a target that matches the host platform](https://github.com/llvm/llvm-project/blob/1431f8f76fa2270cedc88efdebcc236bf374b144/llvm/tools/llvm-rc/llvm-rc.cpp#L423-L436), producing artifacts that target the wrong platform when cross-compiling. To fix this situation, let's explicitly pass a target to `windres` that matches the desired target architecture (all Windows targets can be assumed to generate PE files), which helps ensuring that no different defaults cause miscompilations. I've verified this change to make cross-compilation from an AArch64 MacOS host to the `x86_64-pc-windows-gnullvm` target possible, without breaking cross-compilation to `x86_64-pc-windows-gnu` via the more classical binutils-based (non-LLVM) MinGW toolchain.
Owner
|
Thank you for your contribution, this looks good. Unless I discover some breakage caused by the change, I will merge this shortly. |
Owner
|
Your change is merged and was released in version 0.1.23. |
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.
As stated on its man page,
windresuses a default binutils BFD format when the--targetoption is not explicitly set. This usually works fine with the binutilswindresimplementation even in cross-compilation scenarios, as these have to be set up with a toolchain that's already wired to produce objects for the desired target architecture.However, the LLVM toolchain ships with a
windresimplementation that has a significant behavioral difference in this regard: LLVM is a native cross-platform compiler, which means that no separate toolchains are needed to target a different platform. As such, LLVM'swindresdefaults to a target that matches the host platform, producing artifacts that target the wrong platform when cross-compiling.To fix this situation, let's explicitly pass a target to
windresthat matches the desired target architecture (all Windows targets can be assumed to generate PE files), which helps ensuring that no different defaults cause miscompilations.I've verified this change to make cross-compilation from an AArch64 MacOS host to the
x86_64-pc-windows-gnullvmtarget possible (as that target, being GNU-like, goes through thewindrespath), without breaking cross-compilation tox86_64-pc-windows-gnuvia the more classical binutils-based (non-LLVM) MinGW toolchain.