Rewrite the Readme! by illwieckz · Pull Request #20 · DaemonEngine/native_client

illwieckz · 2026-06-22T00:39:46Z

Google will no longer update it, we fully adopt this!

This is now our Readme!

illwieckz · 2026-06-22T00:41:37Z

@slipher I would like to know the current status of this sentence:

Currently it only works for amd64 host+target (run.py won't work since NaCl targets aren't supported yet).

illwieckz · 2026-06-22T00:44:23Z

+- `src/trusted/`: Source code that's used only by trusted code
+- `src/untrusted/`: Source code that's used only by untrusted code
+- `tests/common/`: Source code for examples and tests.
+- `../third_party/`: Third-party source code and binaries that aren't part of


I guess we can delete this ../third_party mention. The first purpose of the fork was to not require things outside this repository.

slipher · 2026-06-22T09:55:21Z

@slipher I would like to know the current status of this sentence:

Currently it only works for amd64 host+target (run.py won't work since NaCl targets aren't supported yet).

Oh that's out of date indeed. NaCl targets work great. You can built NaCl targets, including the IRT, and test everything together. That's why I complain that using CMake is a regression, since it can't handle the multiple toolchains working in concert. I have verified that Linux stuff generally works and tests pass on the x86_64, x86, and (modulo recent kernel changes...) arm platforms.

slipher · 2026-06-22T09:57:55Z

I haven't tested Windows or Mac yet. But I know that run.py works on at least some Linux targets.

illwieckz · 2026-06-22T15:31:32Z

+
+## Dependencies
+
+- LLVM (must be installed in `/usr/bin`)


@slipher do we still need LLVM be in /usr/bin/?

I suggest to rewrite this line as GCC or Clang.

Yes the LLVM location is still hard-coded. GCC just needs to be in the PATH. And with the other PR LLVM is now optional.

Also the way to use GCC is by putting --no-clang in the command line.

illwieckz · 2026-06-22T15:55:13Z

Currently it only works for amd64 host+target (run.py won't work since NaCl targets aren't supported yet).
Oh that's out of date indeed. NaCl targets work great. You can built NaCl targets, including the IRT, and test everything together.

Great.

That's why I complain that using CMake is a regression, since it can't handle the multiple toolchains working in concert.

CMake can totally use a different toolchain per ExternalProject, and an ExternalProject can build a local directory. This is what we do to build nexe game with PNaCl/Saigo for Unvanquished…

The reason why my CMake implementation doesn't care about IRT right now is that the first goal is to give the ability to build native trusted binaries from Dæmon's external_deps and to extend the compatibility of that (MinGW, etc.).

IRT can be downloaded for now, built with SCons in advance. I'm not excluding the opportunity to build the IRT too, but this is not needed to reach the minimal valuable product which is to make the native loader binary buildable with CMake with the exact same ease we do with the engine itself.

It's totally on purpose that IRT isn't cared about yet, that's a selling point: I don't want the IRT topic to hold back the CMake implementation. The fact the current CMake implementation doesn't build the IRT should not be used against the CMake implementation. It would be holding it back because of the special effort made to not hold it back.

I don't mind that tests remain implemented in SCons forever, run by a CI or something.

slipher · 2026-06-23T05:14:46Z

- LLVM (must be installed in /usr/bin)
+# Native Client loader
+
+This project makes possible to rebuild the Native Client loader for usage with the [Dæmon game engine](https://github.com/DaemonEngine/Daemon). The Dæmon engine is the open-source game engine powering the [Unvanquished game](https://unvanquished.net). The Dæmon engine uses Native Client to securely and portably run downloadable compiled games.


The very long lines are annoying.

slipher · 2026-06-23T05:15:54Z

+
+Native Client is a sandboxing technology by Google, it was used by Chrome extensions and Chrome apps.
+
+Google publicly annouced [in May of 2017](https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly%2C34583.html) the (then-)upcoming deprecation and abandonment of Native Client technologies in favor of WebAssembly, and announced the actual deprecation [in 2020](https://developer.chrome.com/deprecated). But Google also [supported](https://developer.chrome.com/docs/native-client) the Native Client-powered ChromeOS 138 [until July of 2025](https://support.google.com/chrome/a/answer/10314655) and as such continued developpement of some Native Client technologies.


The last link isn't very useful. It goes to a list of all release notes without giving any clue which version I'm supposed to look at.

Not my fault if Google doesn't know how to make web pages… The information is in “ChromeOS 139 release summary” part, in the ”Chrome 139: July 30, 2025” collapsed part. There are anchors for every paragraph but the ChromeOS release paragraphs.

At leas this link is better: https://support.google.com/chrome/a/answer/10314655?&#139
The deprecation mention is waaay below in the summary that has no anchor.

Yeah that looks better

slipher · 2026-06-23T05:17:33Z

+
+- [github.com/DaemonEngine/native_client/issues/13](https://github.com/DaemonEngine/native_client/issues/13)
+
+This fork brings edits to enable the building of NaCl without the Chromium


This could use a more prominent billing, like in the first paragraph. The fact it can be built without gclient or any other Chromium repos.

slipher · 2026-06-23T05:18:40Z

+
+## Build the NaCl loader and boostrap loader
+
+```sh


We can mention the other possible architectures are x86 and arm.

slipher · 2026-06-23T05:25:23Z

- * `tools/`: Utilities such as the plug-in installer.
+- `COPYING NOTICE README.md RELEASE_NOTES documentation/`: Documentation,
+  release, and license information.
+- `SConstruct scons.bat scons scons-out/ site_scons/`: Build-related files.


scons (+ scons.bat I guess) could be dropped as we no longer use a vendored scons, just the scons command normally installed. Though ./scons still works apparently.

slipher · 2026-06-25T05:18:50Z

I don't mind that tests remain implemented in SCons forever, run by a CI or something.

The tests have a lot less value if they don't run against the build that's actually used.

illwieckz · 2026-06-25T06:35:58Z

I don't mind that tests remain implemented in SCons forever, run by a CI or something.

The tests have a lot less value if they don't run against the build that's actually used.

Of course they have less value, but not “lot less”, the code is still tested. The problem lies in the build options if they differ. We may investigate scons testing what's built by CMake.

Scons is not a viable option and I stand on this ground:

$ scons -h
scons: Reading SConscript files ...
Exception: Cannot find a toolchain for x86-32 in native_client/toolchain/linux_x86/pnacl_newlib_raw:
  File "native_client/SConstruct", line 2791:
    if UsingNaclMode(): nacl_env = nacl_env.Clone(
  File "/usr/lib/python3/dist-packages/SCons/Environment.py", line 1610:
    apply_tools(clone, tools, toolpath)
  File "/usr/lib/python3/dist-packages/SCons/Environment.py", line 117:
    _ = env.Tool(tool)
  File "/usr/lib/python3/dist-packages/SCons/Environment.py", line 2033:
    tool(self)
  File "/usr/lib/python3/dist-packages/SCons/Tool/__init__.py", line 265:
    self.generate(env, *args, **kw)
  File "native_client/site_scons/site_tools/naclsdk.py", line 756:
    _SetEnvForNativeSdk(env, root)
  File "native_client/site_scons/site_tools/naclsdk.py", line 109:
    raise Exception("Cannot find a toolchain for %s in %s" %

And especially, Scons is not good enough for the external_build integration, the only reason why it works for the linux amd64 deps is because we build linux amd64 deps on linux amd64 machine. With Scons it only works by luck and we should remove luck.

illwieckz · 2026-06-25T06:41:31Z

As seen with that simple example as scons -h, the Scons technology is defective by design. It's a glorified and overly fragile scripting posing as a build system. Scons encourage for dirty hacks and craves for lacks of methodology. No constraint from the job it's supposed to do means not a single guarantee of result. It's mechanical: Scons grows to madness by design.

slipher · 2026-06-25T06:45:55Z

Scons is not a viable option and I stand on this ground:

CMake is also not a viable option since it can't incorporate more than one toolchain into the build (besides NaCl toolchains I think there are also host-mode tools...). I guess we should just give up.

And especially, Scons is not good enough for the external_build integration, the only reason why it works for the linux amd64 deps is because we build linux amd64 deps on linux amd64 machine. With Scons it only works by luck and we should remove luck.

What do you mean? I can build any Linux architecture from an amd64 machine. I don't know about MinGW since I haven't tried yet.

illwieckz · 2026-06-25T06:59:28Z

What do you mean? I can build any Linux architecture from an amd64 machine.

Our external_deps build script configures compilers (executables, flags, etc.) explicitly in a tightly controlled manner. Scons ignores every instructions, make anything it wants and reinvents the wheel.

The CMake script I wrote will obey to the instructions, and will not pretend to be so special it doesn't have to follow instructions. The purpose is to get what we request, and Scons defeats that.

I don't know about MinGW since I haven't tried yet.

Despite the initial repository wasting hundreds of MB in MinGW tarballs stored in the repository, the code itself assumes MSVC all the way down, doesn't build on MinGW, and even requires both MASM executable and Microsoft include file.

I ported the code to MinGW by the way. And I implemented the build in CMake, including the emulation of MASM with JWasm and the stubbing of the include.

CMake is also not a viable option

The CMake system I wrote is ready to ship and could have been used in external_deps for more than a year already.

illwieckz · 2026-06-25T07:04:27Z

MinGW porting effort:

Despite the name, the last one is also needed outside of CMake, it's the stubbing of some Microsoft ASM include.
I mention CMake because I implemented the JWasm assembler integration in CMake.

readme: rewrite

0ef9a4e

illwieckz force-pushed the illwieckz/readme branch from e9c7c22 to 2c986ac Compare June 22, 2026 00:42

illwieckz commented Jun 22, 2026

View reviewed changes

illwieckz force-pushed the illwieckz/readme branch from 2c986ac to 0ef9a4e Compare June 22, 2026 02:25

slipher mentioned this pull request Jun 22, 2026

Don't use lld when building with GCC #21

Merged

illwieckz commented Jun 22, 2026

View reviewed changes

slipher reviewed Jun 23, 2026

View reviewed changes


		Native Client is a sandboxing technology by Google, it was used by Chrome extensions and Chrome apps.

		Google publicly annouced [in May of 2017](https://www.tomshardware.com/news/chrome-deprecates-pnacl-embraces-webassembly%2C34583.html) the (then-)upcoming deprecation and abandonment of Native Client technologies in favor of WebAssembly, and announced the actual deprecation [in 2020](https://developer.chrome.com/deprecated). But Google also [supported](https://developer.chrome.com/docs/native-client) the Native Client-powered ChromeOS 138 [until July of 2025](https://support.google.com/chrome/a/answer/10314655) and as such continued developpement of some Native Client technologies.


		- [github.com/DaemonEngine/native_client/issues/13](https://github.com/DaemonEngine/native_client/issues/13)

		This fork brings edits to enable the building of NaCl without the Chromium

Uh oh!

Conversation

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

Uh oh!

Uh oh!

illwieckz commented Jun 22, 2026

Uh oh!

illwieckz Jun 22, 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!

slipher commented Jun 22, 2026

Uh oh!

slipher commented Jun 22, 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!

Choose a reason for hiding this comment

Uh oh!

illwieckz commented Jun 22, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

illwieckz Jun 23, 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!

illwieckz Jun 23, 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!

slipher commented Jun 25, 2026

Uh oh!

illwieckz commented Jun 25, 2026

Uh oh!

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

Uh oh!

Uh oh!

slipher commented Jun 25, 2026

Uh oh!

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

Uh oh!

Uh oh!

illwieckz commented Jun 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

illwieckz commented Jun 22, 2026 •

edited

Loading

illwieckz Jun 22, 2026 •

edited

Loading

illwieckz Jun 23, 2026 •

edited

Loading

illwieckz Jun 23, 2026 •

edited

Loading

illwieckz commented Jun 25, 2026 •

edited

Loading

illwieckz commented Jun 25, 2026 •

edited

Loading