Rebasing slipher's work on my CMake and VirtualMachine code by illwieckz · Pull Request #2018 · DaemonEngine/Daemon

illwieckz · 2026-10-16T08:31:21Z

So in #1986 I implemented a lot of refactors meant to makes things easier for Saigo and other things (like the ability to fallback on amd64 on box64 when armhf on arm64 doesn't work, etc.):

Rework external_deps for Saigo and CMake-based NaCl rebuild #1986

This deeply reworked the CMake code, and also deeply reworked the VirtualMachine code, and a whole month has been invested in that effort.

In the meantime @slipher implemented those very appreciated and very wanted and very needed PRs:

It was infinitely less constly to rebase this work over mine than the other way, so that's what this branch does: rebase @slipher's work over my branch.

So I rebased #1998, #2001, #2010 over #1986 then removed every change touching external_deps/build.sh and that made this branch. It also mean that some commits by @slipher touching external_deps/build.sh were split to only keep what was not touching it. The part touching external_deps/build.sh was also rebased but is stored in #1986.

Doing this rebasing took me 10 hours of work, doing it the other way would take many days non-stop.

Because about 5 months have passed, one thing in my commits is now useless: the work I did to turn the multiarch launcher into a generic launcher not specific to armhf or even the nacl loader. Ssuch launcher is then entirely NUKED by some greatly appreciated @slipher's commit rebased here.

Because of how intricated all those changes are, that touch the same code base, I don't want to fight the war of removing that multiarch work under the feet of the later commits just because it turned useless. Cleaning-up such mess would take additional days I don't have. Those commits are following each others properly and that's what matters the most.

Some of the work in some @slipher's commit was already done in my branch, for example almost nothing is left from the commit cmake: SAIGOSDK_ROOT configures NaCl toolchain path from #2010, because it was redundant.

…, implement box64 fallback, detect armhf multiarch support

… taking saigo in account

This reverts commit e65b2650069a9550b885c6fe3249902a439cf137.

Co-authored-by: Thomas Debesse <dev@illwieckz.net>

Set up the chdir and environment variable in posix_spawn. Fixes #1336. Co-authored-by: Thomas Debesse <dev@illwieckz.net>

Remove cvars controlling whether the Linux bootstrap loader is used. Never use bootstrap with the amd64 loader. Always use bootstrap with 32-bit loaders. Co-authored-by: Thomas Debesse <dev@illwieckz.net>

When creating a NaCl (or native exe) VM on Windows, block evironment variables from being passed through to the subprocess as is done on *nix. Probably we do this since there are NACL* variables that can disable secure sandboxing. inheritEnvironment is always false on Windows, but I implemented the true case anyway since it's less code than having the Q_UNUSED and asserting it's false.

Check the Linux sysctl vm.mmap_min_addr only when using the NaCl bootstrap (rather than always when using NaCl). Or equivalently, check it only with 32-bit NaCl runtimes. The bootstrap fails to start when the value is too high to due low fixed address mappings. On ARM at least, sel_ldr proper would also fail with a too-high min address since that disturbs the address space layout. On 64-bit there is neither the bootstrap nor 0-based address space layout so it always works. Co-authored-by: Thomas Debesse <dev@illwieckz.net>

Co-authored-by: Thomas Debesse <dev@illwieckz.net>

The old PNaCl toolchain has been being shipped as part of the deps package, with the host platform for the compilers assumed to be the same as the target platform of the deps package. Experimental Saigo support has thus far required manually downloading the SDK. Now, make the Saigo toolchain auto-downloadable (if USE_NACL_SAIGO=1) independently from the target platform dependencies. This has several advantages: - No need to download the NaCl toolchain if you are not building NaCl. - No need to download a useless NaCl toolchain when cross-compiling. - Toolchain can be downloaded for host systems that don't have a deps package, or where the deps package being used doesn't match the real host system. (The SDK is available for more systems than the deps package.) The toolchain is downloaded from Github and then, like the deps package, extracted into external_deps/.

Add external_deps/sdk-build.sh which can be used as an alternative to auto-downloading Saigo. Like external_deps/build.sh, it builds the dependency package and installs it to the expected location. It is a thin wrapper around the saigo-nacl-sdk CMake build; if you need more control it is better to use CMake directly.

illwieckz · 2026-10-16T09:06:40Z

+    echo "If you want to build only a subset of packages, prefer using the"
+    echo "${REPO_URL} CMake build directly."
+    echo "Some global configuration options are available via environment"
+    echo "variables; see ${REPO_URL}/tree/master/tools/release/build"


By using tab as indentation instead of spaces we would be able to rely on bash indented heredoc.

You can do that if you want.

illwieckz · 2026-10-17T04:32:59Z

-				Log::Warn("Disabling NaCL platform qualification on arm64 kernel architecture.");
-				enableQualification = false;
-			}
+		if (onArm64()) {


OnArm64()

I have a fix for that in #1986, to be imported soon.

illwieckz · 2026-10-20T15:39:38Z

+#if defined(DAEMON_NACL_RUNTIME_LINUX) && defined(YOKAI_ARCH_ARM64)
+	/* We later turn this boolean off when we detect armhf support is not
+	provided on arm64. */
+	bool hasArmhf = true;


Should also exists on armhf, I have a fix for that in #1986, to be imported soon.

illwieckz · 2026-10-20T15:40:17Z

 	SYSTEM_INFO systemInfo;
 	GetNativeSystemInfo(&systemInfo);
-	const bool win32Force64Bit = systemInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64;
+	constexpr bool i686ForceAmd64 = systemInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64;


/Unvanquished/daemon/src/engine/framework/VirtualMachine.cpp:467:41: error: the value of 'systemInfo' is not usable in a constant expression 467 | constexpr bool i686ForceAmd64 = systemInfo.wProcessorArchitecture == PROCESSOR_ARCHITECTURE_AMD64; | ^~~~~~~~~~ /Unvanquished/daemon/src/engine/framework/VirtualMachine.cpp:465:21: note: 'systemInfo' was not declared 'constexpr' 465 | SYSTEM_INFO systemInfo; | ^~~~~~~~~~

I'll test removing the constexpr in #1986 when testing the release build with Unvanquished/release-scripts#46 and import when fixed.

slipher · 2026-10-21T02:11:13Z

This is so big that I can't imagine how to review it. Is there no subset that makes sense on its own? At least sdk-build.sh could be removed from this PR for a start.

slipher · 2026-10-21T02:13:54Z

    add_custom_command(TARGET runtime_deps PRE_BUILD
        COMMAND ${CMAKE_COMMAND} -E copy_if_different
-            ${DEPS_DIR}/nacl_loader${CMAKE_EXECUTABLE_SUFFIX}
+            ${DEPS_DIR}/nacl_loader-${DAEMON_NACL_ARCH_NAME}${CMAKE_EXECUTABLE_SUFFIX}


How can you change the name of the file in the deps archive while using the same old package? I don't understand how this builds.

This is something I need to fix and add temporary backport code. At first all this code was living was posterior to my external_deps rework, so I'm still tracking those leftovers I have to retrofit.

slipher · 2026-10-21T02:14:07Z

What is cmake: implement multi nexe supposed to do?

illwieckz · 2026-10-21T04:08:20Z

What is cmake: implement multi nexe supposed to do?

Generic code to make it straightforward to distribute multiple nexe and loader per engine. Like in the arm64 case where both amd64 and armhf nexes and loader are shipped.

Everything works in my complete branch.

illwieckz · 2026-10-21T06:31:59Z

This is so big that I can't imagine how to review it. Is there no subset that makes sense on its own? At least sdk-build.sh could be removed from this PR for a start.

Each commits will be reviewable and mergeable one by one, but I need this branch to exist to be able to test your commits once rebased (and the rebase done in this order is the least effort).

illwieckz · 2026-10-21T08:10:17Z

@slipher, this can be merged beforehand:

cmake: reword DaemonFlags a bit #2021

illwieckz · 2026-10-21T14:25:03Z

So, with that branch, I managed to build a release unizip, everything built and packaged properly.

I also testing running them, I tested all but linux-armhf (linux-amd64, linux-i686, linux-arm64, windows-amd64, windows-i686, macos-amd64). Everything tested worked as expected.

So I'm now ready to go through the merge process.

Each commits should be reviewable and mergeable one by one, I'll do similar tests on each step. This is just to make sure one thing required from a commit is not mistakenly present in a next one.

illwieckz and others added 12 commits June 26, 2026 03:13

cmake,VirtualMachine: append the architecture name to loader binaries…

f7edb4b

…, implement box64 fallback, detect armhf multiarch support

cmake: rework the code enabling nexe build when there is an nacl sdk,…

6da6685

… taking saigo in account

Revert "f"

e81e633

This reverts commit e65b2650069a9550b885c6fe3249902a439cf137.

cmake: deeply rewrite the NaCl toolchains

6a0a9ab

Refactor: function for Linux arm64 check for VM

27a0537

Co-authored-by: Thomas Debesse <dev@illwieckz.net>

Get rid of nacl_multiarch executable

87eb0e7

Set up the chdir and environment variable in posix_spawn. Fixes #1336. Co-authored-by: Thomas Debesse <dev@illwieckz.net>

Don't use nacl_helper_bootstrap with x86-64 loader

28d8f0e

Remove cvars controlling whether the Linux bootstrap loader is used. Never use bootstrap with the amd64 loader. Always use bootstrap with 32-bit loaders. Co-authored-by: Thomas Debesse <dev@illwieckz.net>

cmake: raise an error when the SDK prefix is not a directory

45d7e8c

Co-authored-by: Thomas Debesse <dev@illwieckz.net>

illwieckz commented Oct 16, 2026

View reviewed changes

Comment thread cmake/DaemonDependenciesDownload.cmake

illwieckz commented Oct 16, 2026

View reviewed changes

illwieckz commented Oct 17, 2026

View reviewed changes

illwieckz commented Oct 20, 2026

View reviewed changes

slipher reviewed Oct 21, 2026

View reviewed changes

illwieckz force-pushed the illwieckz/cmake-saigo branch 2 times, most recently from e33a414 to e5fa711 Compare October 21, 2026 06:24

illwieckz force-pushed the illwieckz/cmake-saigo branch from e5fa711 to a89c459 Compare October 21, 2026 07:49

illwieckz force-pushed the illwieckz/cmake-saigo branch 3 times, most recently from adf91ba to 2aa4bb3 Compare October 21, 2026 14:23

illwieckz force-pushed the illwieckz/cmake-saigo branch 2 times, most recently from 814d459 to 4872437 Compare October 21, 2026 15:26

Conversation

illwieckz commented Oct 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

illwieckz Oct 20, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slipher commented Oct 21, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slipher commented Oct 21, 2026

Uh oh!

illwieckz commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Oct 21, 2026

Uh oh!

illwieckz commented Oct 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

illwieckz commented Oct 16, 2026 •

edited

Loading

illwieckz Oct 20, 2026 •

edited

Loading

illwieckz commented Oct 21, 2026 •

edited

Loading

illwieckz commented Oct 21, 2026 •

edited

Loading

illwieckz commented Oct 21, 2026 •

edited

Loading