Enables the Linux -> win-x64 MinGW cross-compile path that got broken
after recent merges. Still INCOMPLETE — build fails later at missing
DirectX IME headers (DIMM.h) and likely more vendor SDK compat issues.
Commit captures the mechanical fixes so Jakub can adopt/iterate.
Changes:
1. toolchains/linux-mingw64.cmake — MinGW cross-compile toolchain
(Windows x86_64 target, mingw-w64 gcc/g++/windres, lld linker).
2. CMakeLists.txt:
- MSVC-only flags (/MP, /Zi, /DEBUG linker flag) gated behind
if(MSVC) — they break MinGW gcc which treats /MP as filename.
- UNICODE / _UNICODE defined globally (was inside if(MSVC), but
WIN32_FIND_DATA etc. need it everywhere).
- __int64 -> long long compile definition for non-MSVC compilers
so the Granny SDK header parses.
- -mssse3 compile option for non-MSVC so _mm_shuffle_epi8 in
EterLib/GrpImageTexture.cpp inlines correctly.
3. Include fixes for Linux case-sensitive filesystem and stricter
GCC standard library:
- Poly/StdAfx.h: backslash in include path -> forward slash.
- EterBase/Stl.h: <SSTREAM> -> <sstream>.
- EterBase/Utils.h: add <cmath> so cos() in templates resolves.
- AudioLib/MaSoundInstance.h: add <cstdint> so uint8_t vector
template argument is valid.
- AudioLib/Type.h: add <cstdint> for uint32_t.
- extern/include/utf8.h: add <cstdint> for uint8_t/uint16_t.
- EffectLib/Type.h: typedef typename std::vector<...>::iterator
(dependent-name C++11+ compliance).
Not committed (needs manual recreation per checkout, or git-tracking
them needs buy-in):
- 60+ stdafx case-variant symlinks (stdafx.h, StdAfx.h, Stdafx.h)
- 7 directory case symlinks (Eterlib, eterLib, eterBase, Gamelib,
gamelib, Eterbase, eterbase)
- header case-variant symlinks in individual dirs
Still failing at:
- src/EterLib/IME.h:7 wanting DIMM.h (DirectX IME, not in extern/
and not shipped with mingw-w64). Needs either a shim header, a
#ifdef _MSC_VER guard, or vendoring the Microsoft DirectX IME SDK.
Work done over ~2h trying to get a fresh release cycle through from
Linux. Stopping here because each fix exposes another vendor/compat
issue that benefits from Jakub's context of the build history.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Loads packs one by one so that duplicate file resolution
follows a deterministic order (last pack wins). Parallel loading made
the effective order depend on lock acquisition order, allowing older
packs to override newer ones. Sequential load stays under ~1s (~350ms
on typical hardware), so the performance tradeoff is considered acceptable.
