Fix Windows/MinGW cross-compilation of the yep packer#2
Open
SchwartzKamel wants to merge 2 commits into
Open
Conversation
yep_set_fs_times() uses `struct _stat` and `_stat()` on the _WIN32 branch,
but <sys/stat.h> was only included in the non-Windows branch. With MinGW 15.x,
`_stat` is a macro expanding to `_stat64i32`, whose declaration lives in
<sys/stat.h>. Without that include the Windows build fails:
error: implicit declaration of function '_stat64i32'
Add <sys/stat.h> to the _WIN32 include block so the packer builds under MinGW.
pack_resources() runs the `yep` packer at build time to produce .yep
archives. When the consuming project cross-compiles (e.g. Linux host ->
Windows target), the in-tree `yep` target is built for the target platform,
so the resource-packing step tried to execute a target binary (e.g. a
Windows PE) on the build host and failed with "Exec format error".
Add a host/target split:
- yep's CMakeLists.txt now publishes, via global properties, which packer
pack_resources() should invoke:
* native build -> the in-tree `yep` target (unchanged behavior)
* cross build -> a host-runnable packer
Global properties are used so the choice is visible from the consumer
scope (FetchContent adds yep in a child scope) and is recomputed on every
configure (so it stays correct across reconfigures).
- When cross-compiling and no packer is supplied, build one for the host via
ExternalProject_Add. The nested CMake invocation does not inherit the cross
toolchain, so it configures for the host; being non-cross, it does not
recurse. The host binary is emitted to a deterministic path (robust for
multi-config generators).
- Consumers may instead set YEP_HOST_EXECUTABLE to a prebuilt host packer
(validated to exist), and YEP_HOST_C_COMPILER / YEP_HOST_CXX_COMPILER to
override host compiler detection.
Verified end-to-end with a mingw-w64 cross build: the host ELF packer is
built and run, producing resources.yep, while the in-tree target remains a
Windows PE. Native (non-cross) builds are unchanged.
Member
|
#2 is an interesting problem, unique to MingW cross compilation. I'll have a look at this soon and see if I can think of a better way... |
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
Fixes two issues that break building the
yepresource packer for Windows when cross-compiling from a Linux host with MinGW (mingw-w64 15.x), which is how the yoyoengine CTF game distribution is built.1.
yepfs.cfails to compile under MinGW 15.xyep_set_fs_times()usesstruct _stat/_stat()on the_WIN32branch, but<sys/stat.h>was only included on the non-Windows branch. Under MinGW 15.x,_statis a macro expanding to_stat64i32, declared in<sys/stat.h>. Without the include:Reproduced and fixed; with the include,
yepfs.ccompiles cleanly for Windows (0 errors).2. Cross builds try to run the target packer on the host
pack_resources()executes theyepbinary at build time to produce.yeparchives. When the consuming project cross-compiles, the in-treeyeptarget is built for the target platform, so the pack step tries to run a Windows PE on the Linux host:This adds a host/target split: yep publishes (via global properties) which packer
pack_resources()should run — the in-tree target for native builds, or a host-runnable copy when cross-compiling. The host copy is built viaExternalProject_Add(a fresh CMake invocation that doesn't inherit the cross toolchain, so it configures for the host; being non-cross it doesn't recurse). Consumers may instead pointYEP_HOST_EXECUTABLEat a prebuilt host packer, withYEP_HOST_C_COMPILER/YEP_HOST_CXX_COMPILERto override host compiler detection.Testing
End-to-end with a real mingw-w64 cross build of a consumer that uses
FetchContent+pack_resources():resources.yep; the in-tree target remains a Windows PE (what previously ran and failed).yeptarget is used to pack.Both produce identical archives. Hardened for multi-config generators (deterministic host output path) and toolchain/env leakage (toolchain cleared in the nested build; explicit host-compiler overrides available).