Repository navigation
Merging my work #19
Description
Things can be merged in this order:
- Disable DEP qualifications outside of MSVC #38
- Restore ld_bfd finding libgcc to link with it, fix bootstrap build for linux-armhf #33
- Cleanup DEPS, BUILD.gn, make build/ available #27
- Fix incompatible pointer type in Windows code (nacl_host_dir.c) #29
- Fix incompatible pointer type in Windows code (nacl_host_desc.c) #30
- Make the loader runs on 16k page size kernel with SCons (2) #16
- Make the loader code compatible with MinGW (2) #17
- Skip the CPU detection on MinGW like MSVC for amd64 #22
- Prepare for the CMake plumbing to build the loader with MinGW (2) #18
- CMake plumbing to build the loader (2) #14
- CMake plumbing to build tls_edit #43
- Make the loader runs on 16k page size kernel with CMake (2) #15
- WIP: CI #39
Activity
illwieckz commentedon Jun 27, 2026
As mentioned there:
The whole can be tested at once with my
illwieckz/stagingbranch:slipher commentedon Jun 27, 2026
I've been trying to get the Windows build running using the Chromium toolchains for a couple days, so that I can test whether there are any regressions. It's a bit slow going since there some annoying issues. For example the non-Linux toolchain lists were deleted, so I have to restore them by reverting that commit.
I also tried to set it up with your Saigo toolchain build, but the Windows executables didn't seem to work (reported on the other repo).
illwieckz commentedon Jun 27, 2026
I suspect the Windows build went wrong: the tarball is way smaller than some of my previous builds. I'll retry them.
Link?
slipher commentedon Jun 27, 2026
DaemonEngine/saigo-nacl-sdk#2
slipher commentedon Jun 30, 2026
Finally got Windows builds going good with Scons so I can run the tests. There were a lot of build system mysteries to unravel.
Why are there two build systems? The GN build system is/was used to build NaCl for Chromium. But it mostly
doesn't have any tests. So the Scons build continued being maintained for CI and testing purposes. (The reliability of testing with a different build is questionable though, as this software is extremely sensitive to compiler/linker/etc. flag changes!)
How are you even supposed to build with MSVC? There were a few layers of bit rot:
--no-clangmust always be specified or it will use a nonexistent Clang path.I learned from commit 406521b that as of 2020,
cl.exe(regular MSVC compiler) uses were mostly removed from Chromium builds. They are using clang-cl instead. The Scons file can also be made to work with clang-cl with very minor modifications.slipher commentedon Jul 1, 2026
I've run across a potential issue with using MinGW. A crash handling routine in
src/trusted/service_runtime/win/exception_patch/intercept.Sassumes the "native" ABI for thread-local storage. Most current MinGW toolchains are using a different one, "emutls". Apparently the option to use the native ABI was recently added with GCC 16, but it wouldn't be available in many distros yet. It sounds like this is something that must be configured, so just because a MinGW toolchain updated to GCC 16 doesn't necessarily mean it's using the new ABI.This is the kind of stuff I'm talking about when I say running the tests with a different build would provide a lot less value for this software in particular. I think my external crash test should be able to catch this one, however. Could you try that with a MinGW build?
slipher commentedon Jul 1, 2026
Note that clang-cl is said to already use the native TLS ABI, so that could be alternative to MinGW if cross-compiling is desired, though there is the annoying bit of needing to download a non-libre Microsoft SDK to get the headers. As mentioned above Chromium built everything with clang-cl; the MSVC build which is working now on the
slipher/fixed-upstreambranch can be modified to use clang-cl with a patch of less than 10 lines. (Cross-compiling with clang-cl would be somewhat more involved though.)illwieckz commentedon Jul 1, 2026
Thanks for those investigations! That's very helpful! ❤️
It looks like we will have good quality Native Client… 🙂️
illwieckz commentedon Jul 1, 2026
I'll do, but probably not before some days.
illwieckz commentedon Jul 9, 2026
@slipher Right now when I attempt to run the nacl loader on Wine it fails:
I tried a pnacl and a saigo nexe build, in both case it was using the loader built with mingw.
I don't know how to run the
crash_test.pytool but I wanted to test a simple run before.One can test building the game with mingw-built nacl_loader and saigo using the
illwieckz/depsengine branch (preview packages are provided).I attempted to run by hand my old helloworld (likely built with PNaCl at the time), and it didn't printed “hello world“”:
illwieckz commentedon Jul 10, 2026
Well, it doesn't work anymore on
linux-armhfon my end.illwieckz commentedon Jul 10, 2026
For this one it looks like I had a bad irt. I don't know from where I got it. With the one from the old naclsdk it works.
slipher commentedon Jul 10, 2026
I can test this if you tell me the specific file to download.
illwieckz commentedon Jul 10, 2026
Nothing to download by hand, just building the usual way will download the preview package.
If you want to download them by hand, they are there:
illwieckz commentedon Jul 10, 2026
And here are my helloword nexe:
I forgot to say it, but despite no specific error message (but the missing of the actual
hello worldone), the loader returned with a non-zero return code.Edit: The return code was
1.slipher commentedon Jul 13, 2026
I tried the nacl_loader + irt_core from https://dl.unvanquished.net/test/deps/windows-amd64-mingw_12.tar.xz with the 0.56.2 release. The game doesn't start: I immediately get "nacl_loader.exe has stopped working". That's about what I expected since there are some missing pieces relating to thread-local storage:
THREADmacro which is supposed to be an attribute to use TLS is defined to the wrong thing for MinGW. If you fix it, the symbol names change, which causes some (GNU) assembler code to fail to link.I have a scons mingw build somewhat working and also have a native TLS toolchain available via MSYS so I'll see if I can get it to work with that.
slipher commentedon Jul 13, 2026
Also you didn't build an i686 Windows version did you? It looks like there are a lot of missing pieces in the source still, where there is MSVC inline assembly with no alternative path. In view of Unvanquished/Unvanquished#3572 maybe the best thing to do would be to keep using the old Google sel_ldr instead of trying to rebuild it, even if we make a few more 32-bit Windows releases.
illwieckz commentedon Jul 13, 2026
It looks like I forgot to upload them, now done:
Yeah, I'm not excluding the possibility to rely on a different origin for some platforms, though we may prefer to rebuild the Windows loaders with MSVC and put it as a download on the
native_clientGitHub than to forever rely on that annoying download from Google.The same can be said for the IRT. I don't really see the point of building the IRT in the
external_depsscript and adds Saigo as required dependencies to build the dependencies. A small download from our the GitHub would be fine. Right now in my revampedexternal_deps/build.shscript I still copy the IRT from the old Google PNaCl tarball.illwieckz commentedon Jul 13, 2026
How is built
src/trusted/service_runtime/arch/x86_64/nacl_switch_unwind_win.asmwhen usingclang-cl? I use JWasm to cross-compile the MinGW build witout MASM.slipher commentedon Jul 13, 2026
With MASM, same as before. The comment there is precisely 'last use of cl.exe', not last use of Visual Studio. It's just the classic Microsoft C/C++ compiler they wanted to avoid in particular, not the VS toolchains in general. Note that VS also ships clang-cl.
illwieckz commentedon Jul 13, 2026
Ah, so they don't cross-compile…
slipher commentedon Jul 14, 2026
Good news! I tried building using a patched Scons build with a MinGW GCC 16.1 provided by MSYS2 (but with the one assembler file still compiled with MASM) and it compiles with the thread-local attributes correctly set. Almost all tests pass and
crash_test.pyworks. So MinGW CMake plans can proceed, but you won't be able to build with the compilers in Debian stable. It requires at least GCC 16 and needs to be configured with the "native" TLS. When the attribute is fixed and you try to build with an incompatible toolchain, you'll get link errors.illwieckz commentedon Jul 14, 2026
Nice! For now even Debian
unstableis still at GCC15 unfortunately. But that doesn't prevent to do the plumbing. I guess that for Windows we will build the NaCl runtime outside ofexternal_depsand make a package to download inexternal_depsinstead, until some GCC-16-based MinGW surfaces.slipher commentedon Jul 28, 2026
I tried renting an arm64 VPS to test the case of armhf running on a 64-bit host. But it turned out the hardware does not have support for running 32-bit programs. Maybe such support is actually uncommon...
illwieckz commentedon Jul 29, 2026
The 32-bit apps support is optional in both ARMv8 and ARMv9. Usually ARMv8 supports both (this is also the architecture that introduced 64-bit so it's understandable they massively kept compatibility with older tech), but 32-bit is becoming rarer on ARMv9. All OpenGL 3+/Vulkan single boards I tested (Raspberry Pi 4, 5, Banana Pi M5, Orange Pi 5, NanoPI R5C) had 32-bit support. But they're all ARMv8 as far as I know.
I have a Dæmon branch able to run box64 on arm64 when armhf isn't there anyway.
slipher commentedon Oct 5, 2026
Are you still dead-set on this CMake port? It's an enormous waste of time and pointless complexity to have two build systems. Scons can be installed as a Python module so there is no difficulty in installing on Mac or whatever. The loader can only be built for a small fixed set of platforms, so you can't say you need YOKAI to get it to build on FreeBSD or something like that.