I have a local branch that attempts to detect if armhf hardware support is present on linux-arm64, and if yes, it uses the armhf loader, if not, it uses the amd64 loader on box64.
The code path to use one or the other works (except I haven't test on hardware with 32-bit that it actually detects the missing support), on my system supporting 32-bit it says the support is there and it uses the armhf loader.
I added a cvar to force the disablement armhf multiarch and then it uses the amd64 loader on box64 as expected.
I started implementing the bundling of box64 in external_deps too.
So the whole thing is almost there.
Anyway, whatever the loader, I get different errors with the NativeClient code, that may be related to Saigo (I used self-built loader and self-built Saigo compiler):
Unvanquished 0.56.2 Linux arm64 (GCC_10.2.1:aarch64-linux-gnu-g++) Jul 3 2026
…
Using loader args: nacl_helper_bootstrap-ldarmhf nacl_loader-armhf --r_debug=0xXXXXXXXXXXXXXXXX --reserved_at_zero=0xXXXXXXXXXXXXXXXX -Q -v -B irt_core-armhf.nexe -e -i 100:18 -- cgame-armhf.nexe 100
…
Loaded cgame VM module in 270 msec
cgame NaCl armhf (Saigo_21.0.0/Clang_21.0.0:arm-nacl-clang++) Jul 3 2026
Loading Lua plugin using a new Lua state.
Wrote crash dump to crashdump/crash-nacl-CGame-1783087446249.dmp
Warn: Error during initialization: CGame VM: Crashed with NaCl exception
Unvanquished 0.56.2 Linux arm64 (GCC_10.2.1:aarch64-linux-gnu-g++) Jul 3 2026
…
Using loader args: box64 nacl_loader-amd64 -Q -v -B irt_core-amd64.nexe -e -i 100:18 -- cgame-amd64.nexe 100
…
Loaded cgame VM module in 5906 msec
cgame NaCl amd64 (Saigo_21.0.0/Clang_21.0.0:x86_64-nacl-clang++) Jul 3 2026
Loading Lua plugin using a new Lua state.
Loaded font face 'unifont' [regular] from 'fonts/unifont.ttf'.
Loaded font face 'Roboto' [bold] from 'fonts/Roboto-Bold.ttf'.
Loaded font face 'Roboto' [italic, bold] from 'fonts/Roboto-BoldItalic.ttf'.
Loaded font face 'Roboto' [italic] from 'fonts/Roboto-Italic.ttf'.
Loaded font face 'Roboto' [regular] from 'fonts/Roboto-Regular.ttf'.
Loaded font face 'FontAwesome' [regular] from 'fonts/fontawesome-webfont.ttf'.
Loaded font face 'DejaVu Sans' [regular] from 'fonts/DejaVuSansCondensed.ttf'.
Loaded font face 'Material Icons' [regular] from 'fonts/MaterialIcons-Regular.ttf'.
Warn: Unable to open file }.
Warn: Unable to open file {.
Warn: Error during initialization: IPC: Timed out while waiting for VM message
Actually that parsing error isn't new, maybe we got them with the armhf build before. It would be funny that amd64 on arm64 would produce similar bugs as armhf.
I have a local branch that attempts to detect if
armhfhardware support is present onlinux-arm64, and if yes, it uses thearmhfloader, if not, it uses theamd64loader onbox64.The code path to use one or the other works (except I haven't test on hardware with 32-bit that it actually detects the missing support), on my system supporting 32-bit it says the support is there and it uses the
armhfloader.I added a cvar to force the disablement
armhfmultiarch and then it uses theamd64loader onbox64as expected.I started implementing the bundling of
box64inexternal_depstoo.So the whole thing is almost there.
Anyway, whatever the loader, I get different errors with the NativeClient code, that may be related to Saigo (I used self-built loader and self-built Saigo compiler):
armhf:amd64:Actually that parsing error isn't new, maybe we got them with the
armhfbuild before. It would be funny thatamd64onarm64would produce similar bugs asarmhf.