Repository navigation
Building the NativeClient loader as part of the engine build? #1879
Description
Activity
- changed the title
[-]Building the native_client loader as part of the engine build?[/-][+]Building the NativeClient loader as part of the engine build?[/+]on Dec 18, 2025 I do remember having read that either windows-amd64 or windows-i686 may rely on MinGW for building one file even when MSVC is the compiler
I found it, it's mentionned in the comment in my CMake file (itself copied from SCons):
# We use the GNU assembler (gas) on Windows so that we can use the # same .S assembly files on all platforms. Microsoft's assembler uses # a completely different syntax for x86 code. #FIXME: Use x86_64-w64-mingw32-as.exe or x86_64-w32-mingw32-as.exe on MSVC for .S files.So that's an MSVC limitation only, so we may build the Windows NaCl loader as part of the engine build when building with MinGW, and ship it as prebuilt for MSVC.
Sounds like a bad idea to me. NaCl only builds on a finite set of platforms so we wouldn't gain any more portability. As hinted above it uses some build tools that we currently don't depend on, so there would be a greater chance of the build not competing successfully with some toolchains. NaCl is something that very few people will want to hack on, so there is little benefit in easily modifying it. I don't understand what the benefit is supposed to be.
The benefit would be to not enforce the download of a precompiled binary when the build is straightforward on the platform. On Linux with my CMake configuration it would just require to add the NaCl loader as a CMake subproject (just to not pollute the compiler flags) in Dæmon CMake. The loader is a very important part of the engine, and is fast to build.
Right now we ship the loader (
nacl_loader,nacl_helper_bootstrap) with the external deps.With the ongoing efforts of making it rebuildable easily, especially the CMake effort, it will become possible to rebuild the loader as part of the engine build itself:
The proposal is that it would be rebuilt as a CMake sub-project, to not pollute engine CFLAGS and don't get CFLAGS pollution from engine.
We may as a start only build the native loader and ship the irt nexe with the external deps, since we also have a plan to repackage saigo, if we manage to build the irt nexe with saigo we may include the irt nexe build as part of the engine build too, and that could be done for every platform.
There are special cases:
-m32would be enough). We would also need to ship the armhf libc in the external deps for the loader, unless we find a way to get a working statically built loader.