There was a conflict with per-target compile flags and the PCH.
The PCH was causing the game code to be built without the inlining
flags actually taking effect (internal `src/dusk` files did not use
them), which caused mods to fail to resolve static functions for
hooks. Fix: split Dusklight internals (`src/dusk/`) into a separate
static library altogether, cleanly allowing us to disable inlining
and patching flags only for internal code while also fixing the PCH
flags issue.
Additionally, this updates symgen to v1.3.4, which includes a fix
for GCC function fragments and specializations getting resolved as
display name aliases, conflicting with the actual functions.
Aurora also updated to include https://github.com/encounter/aurora/pull/244
It turns out this approach can't work on
ARM64 Windows due to the relocation model,
so we can simplify and just remove it
entirely.
Separately, I will make a commit tagging
all game data as DUSK_GAME_DATA, so things
work uniformly across cl/clang-cl and x64/
arm64.
`symgen exports` replaces -export_dynamic on Apple and curates
Android's dynamic symbols with a version script. `symgen stub` then
emits sdk/stub-{macos,ios,tvos}-<arch>, sdk/stub-android-<arch>.so,
and sdk/windows-<arch>.lib.
Apple: mods are now MH_BUNDLE (.so) linked with -bundle_loader,
replacing the deprecated (on iOS) -undefined dynamic_lookup.
Windows: clang-cl mods link dusklight.exe directly; lld's mingw driver
synthesizes imports from the export table. cl still requires the
import library.
* ci: Try arm64 Linux/Windows builds
* Update aurora
* Explicitly set CMAKE_SYSTEM_PROCESSOR on Windows
* Update build-appimage.sh for aarch64
* Set Rust_RUSTUP_INSTALL_MISSING_TARGET=ON
* Use CMAKE_SYSTEM_PROCESSOR normalization for jpeg-turbo build too
* MSVC ARM64 support for freeverb
Luke Street