CMake plumbing to build loader by illwieckz · Pull Request #2 · DaemonEngine/native_client

illwieckz · 2025-04-07T18:42:02Z

I added some CMakeLists.tx code to rebuild sel_ldr and nacl_helper_bootstrap.

This relies on some unified DaemonPlatform framework copied from DaemonEngine/Daemon#1641 on purpose to give this CMake code the same easiness at doing cross-compiled builds.

I need help to complete the src/trusted/service_runtime/CMakeLists.txt file.

The CMakeLists.txt files are a rewrite of the file SConstruct and *.scons files with all unit tests deleted. Remaining unported code is commented out with lines starting with #TODO:.

Build status:

system	arch	build `sel_ldr`	build `nacl_helper_bootstrap`	run `helloworld` nexe
windows	amd64	not tested	N/A	not tested
windows	i686	not tested	N/A	not tested
mingw	amd64	✅️	N/A	not tested
mingw	i686	✅️	N/A	not tested
linux	amd64	✅️	✅️	✅️
linux	i686	✅️	✅️	not tested
linux	armhf	✅️	✅️	not tested
linux	armhf 16k	✅️	✅️	not tested
linux	armel	✅️	✅️	not tested
linux	mips	✅️	✅️	not tested
android	armel	✅️	✅️	❌️
macos	amd64	✅️	N/A	not tested

Dynamically linked loader:

system	arch	shared link `sel_ldr`	run `helloworld` nexe
windows	amd64	not tested	not tested
windows	i686	not tested	not tested
mingw	amd64	✅️	not tested
mingw	i686	✅️	not tested
linux	amd64	✅️	✅️
linux	i686	✅️	not tested
linux	armhf	✅️	✅️
linux	armhf 16k	✅️	not tested
linux	armel	✅️	not tested
linux	mips	✅️	not tested
android	armel	✅️	not tested
macos	amd64	✅️	not tested

~~Statically linked loader:~~ NOW REMOVED.

system	arch	static link `sel_ldr`	run `helloworld` nexe
windows	amd64	not implemented	not implemented
windows	i686	not implemented	not implemented
mingw	amd64	✅️	not tested
mingw	i686	✅️	not tested
linux	amd64	✅️	✅️
linux	i686	✅️	not tested
linux	armhf	✅️	❌️ segfault
linux	armhf 16k	✅️	not tested
linux	armel	✅️	not tested
linux	mips	✅️	not tested
android	armel	✅️	not tested
macos	amd64	✅️	not tested

Things like linux-mips were tested only because I ported the SCons code to CMake for completeness and make sure I forgot nothing.

I tested android-armel because I remember that in the past @cu-kai tried to get daemon-tty running on Android to get a console for his server.

Only for amd64 host and target. nacl_helper_bootstrap also builds. - Check in linux_syscall_support.h (like we did for Breakpad) - Add a hacky symlink so we don't have to include the repository's parent directory or name it "native_client" - Use LLVM from /usr/bin instead of Chromium toolchains - Remove sysroot flags (depend on host system instead) - Disable setup of NaCl-target toolchains in scons scripts

Disable GDB tests by default and when they are disabled don't try to look for a 2nd NaCl toolchain just to grab its GDB. GDB tests on Linux are broken for me anyway in upstream with the incompatibly old curses lib dependency issue.

With some minor fixes, the build is able to run and produce an irt_core binary when configured with the Saigo toolchain. Added documentation how to do this to the README. Still keeping the 'if nacltools' guards I added so that sel_ldr can be built without acquiring any NaCl toolchains.

slipher · 2025-04-07T21:42:40Z

Is it really so bad to use Scons? Unlike CMake, it can handle multiple toolchains, which makes it well-suited for this repo. Also if we keep the same build system, we can easily compare things between our version and upstream.

illwieckz · 2025-04-07T21:52:38Z

Is it really so bad to use Scons?

Yes. 😅️

Unlike CMake, it can handle multiple toolchains, which makes it well-suited for this repo.

Uh, totally not. The Scons scripts are not compatible with cross-compiling to begin with.

First purpose of this effort is to make possible to use multiple toolchains.

slipher · 2025-04-07T22:08:39Z

The Scons scripts are not compatible with cross-compiling to begin with.

Wrong. With Chromium native_client I can do ./scons --mode=nacl,opt-linux platform=x86-32 sel_ldr irt_core_raw or ./scons --mode=nacl,opt-linux platform=arm sel_ldr irt_core_raw and everything completes successfully and produces executables of the expected architectures.

illwieckz · 2025-04-07T22:26:08Z

How do I build with MinGW for Windows on Linux? For Linux Arm?

How do I make a static nacl_loader? How do I rebuild with a 16k PageSize for Arm?

This scons stuff is over-convoluted…

illwieckz · 2025-04-07T22:29:08Z

Wrong. With Chromium native_client I can do ./scons --mode=nacl,opt-linux platform=arm sel_ldr

With this exact command I get that:

Exception: Cannot find a toolchain for arm in toolchain/linux_x86/pnacl_newlib_raw:
  File "SConstruct", line 2799:
    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 "site_scons/site_tools/naclsdk.py", line 756:
    _SetEnvForNativeSdk(env, root)
  File "site_scons/site_tools/naclsdk.py", line 109:
    raise Exception("Cannot find a toolchain for %s in %s" %

I have arm-linux-gnueabihf-gcc (from the gcc-arm-linux-gnueabihf package), and also clang.

slipher · 2025-04-07T23:59:00Z

How do I build with MinGW for Windows on Linux?

Found some documentation: https://github.com/DaemonEngine/native_client/blob/master/docs/build_systems.md. Although cross-architecture builds are supported, cross-OS builds are not. And you can't build with MinGW at all as it is designed for the MSVC toolchain. It seems building with MinGW would imply a porting effort beyond just the build system, as there is, e.g., a Microsoft assembler file.

The lack of cross-OS support would seem to be a limitation of Native Client though, not a limitation of Scons.

For Linux Arm?

I posted that in the previous message.

Wrong. With Chromium native_client I can do ./scons --mode=nacl,opt-linux platform=arm sel_ldr

With this exact command I get that:

You're getting an error finding a PNaCl toolchain, which should have been downloaded by gclient or whatever. Make sure you are in a fully equipped Chromium environment.

illwieckz · 2025-04-08T01:21:03Z

Wrong. With Chromium native_client I can do ./scons --mode=nacl,opt-linux platform=arm sel_ldr

With this exact command I get that:

You're getting an error finding a PNaCl toolchain, which should have been downloaded by gclient or whatever. Make sure you are in a fully equipped Chromium environment.

Why do I need a PNaCl toolchain to build an Arm sel_ldr?

The lack of cross-OS support would seem to be a limitation of Native Client though, not a limitation of Scons.

Yes, all that scons code in the repository is not meant for cross-compilation, that's what I meant.

And you can't build with MinGW at all as it is designed for the MSVC toolchain. It seems building with MinGW would imply a porting effort beyond just the build system, as there is, e.g., a Microsoft assembler file.

Very annoying… I have seen they also have some Cygwin code, so I wonder if that can be used on MinGW, I haven't looked at this deeply though.

illwieckz · 2025-04-08T01:26:26Z

Sorry, the output of ./scons --mode=opt-linux platform=arm sel_ldr is (I forgot to remove the nacl mode):

AttributeError: 'SConsEnvironment' object has no attribute 'Program':
  File "SConstruct", line 3889:
    BuildEnvironments(selected_envs)
  File "site_init", line 198:
    
  File "/usr/lib/python3/dist-packages/SCons/Util/envs.py", line 242:
    return self.method(*nargs, **kwargs)
  File "site_scons/site_tools/defer.py", line 148:
    func(env)
  File "site_init", line 125:
    
  File "/usr/lib/python3/dist-packages/SCons/Script/SConscript.py", line 598:
    return _SConscript(self.fs, *files, **subst_kw)
  File "/usr/lib/python3/dist-packages/SCons/Script/SConscript.py", line 285:
    exec(compile(scriptdata, scriptname, 'exec'), call_stack[-1].globals)
  File "src/trusted/validator_arm/build.scons", line 271:
    nexe = untrusted_env.ComponentProgram(test, 'testdata/' + test + '.S',
  File "/usr/lib/python3/dist-packages/SCons/Util/envs.py", line 242:
    return self.method(*nargs, **kwargs)
  File "site_scons/site_tools/component_builders.py", line 485:
    out_nodes = env.Program(prog_name, *args, **kwargs)

illwieckz · 2025-04-08T03:29:40Z

This can already build sel_ldr on linux-amd64.

illwieckz · 2025-04-08T04:50:13Z

This can now rebuild sel_ldr on linux-armhf.

illwieckz · 2025-04-08T05:18:44Z

This can now rebuild sel_ldr on linux-i686.

illwieckz · 2025-04-08T06:10:58Z

This can now rebuild nacl_helper_bootstrap on both linux-amd64, linux-i686 and linux-armhf.

illwieckz · 2025-04-08T06:55:36Z

This can now rebuild sel_ldr on macos-amd64.

illwieckz · 2025-04-08T10:15:37Z

By using JWasm as a MASM-compatible assembler I can cross-build (from Linux to Windows with MinGW) the sel_ldr binary for windows-amd64 as long as I put ksamd64.inc, kxamd64.inc and macamd64.inc in ../../src/trusted/service_runtime/arch/x86_64.

I got them from:

https://github.com/tpn/winsdk-10/tree/master/Include/10.0.16299.0/shared

illwieckz · 2025-04-08T10:32:16Z

Using the same tricks, it is now possible to rebuild sel_ldr for windows-i686 with MinGW.

It means that it is now possible to rebuild the loader for all the DæmonEngine platforms using CMake (including the related nacl_bootstrap_helper when needed), on macOS for the macOS loader, on Linux for all other platforms.

This test is using some custom macros instead of googletest and ASSERT_EQ apparently double-evaluates the arguments if the assertion fails.

Use --orphan-handling=unwanted when linking nacl_helper_bootstrap which makes the linker discard any sections not explicitly mentioned in the linker script. This prevents the linker from producing a defective binary with overlapping PT_LOAD headers when using GCC on certain distros such as Ubuntu and Arch that have it configured to produce a .note.gnu.property section

See d281e6a

illwieckz · 2026-06-09T17:14:39Z

I rebased on the Yokai framework:

cmake: make DaemonPlatform, Architecture, Compiler, etc. autonomous and reusable as Yokai framework Daemon#1641

illwieckz · 2026-06-19T00:05:21Z

@slipher I now rebased on the latest version of Yokai, this should be ready.

slipher and others added 8 commits April 3, 2025 03:43

Init from upstream 78751ab2bd2918cdbe4d849412463351088d2e90

58d6df9

Allow using system scons instead of chromium one

5cf07ef

Try to stop Clang 17+ warn on undefining __STDC_HOSTED__

2aea5fc

Avoid depending on another NaCl toolchain for gdb

b20136b

Disable GDB tests by default and when they are disabled don't try to look for a 2nd NaCl toolchain just to grab its GDB. GDB tests on Linux are broken for me anyway in upstream with the incompatibly old curses lib dependency issue.

cmake: add MinGW CMake toolchains for cross-compilation

15db477

cmake: add CMake scripts to build sel_ldr and nacl_helper_bootstrap

3362c04

illwieckz marked this pull request as draft April 7, 2025 18:42

illwieckz force-pushed the illwieckz/cmake branch 2 times, most recently from 2775579 to 993144e Compare April 7, 2025 20:34

illwieckz force-pushed the illwieckz/cmake branch from 02ffbba to b588d34 Compare April 8, 2025 10:12

illwieckz force-pushed the illwieckz/cmake branch 2 times, most recently from 37f0e62 to 0c40165 Compare April 8, 2025 10:30

illwieckz force-pushed the illwieckz/cmake branch from 0c40165 to 8d956b8 Compare April 8, 2025 10:38

slipher added 2 commits December 15, 2025 19:00

Fix GCC warning about macro string literal concat

a7dbda7

Fix GCC fclose warning in a test

e7fc598

This test is using some custom macros instead of googletest and ASSERT_EQ apparently double-evaluates the arguments if the assertion fails.

illwieckz force-pushed the illwieckz/cmake branch 5 times, most recently from 4ad638b to c725772 Compare December 17, 2025 10:22

illwieckz added the enhancement New feature or request label Dec 17, 2025

slipher and others added 2 commits December 17, 2025 21:10

cmake: add the Yokai CMake framework

e253162

illwieckz force-pushed the illwieckz/cmake branch 4 times, most recently from 19d4e54 to 8a51eee Compare December 18, 2025 10:15

illwieckz mentioned this pull request Dec 18, 2025

Building the NativeClient loader as part of the engine build? DaemonEngine/Daemon#1879

Open

illwieckz force-pushed the illwieckz/cmake branch 5 times, most recently from ecaccae to a87e12d Compare December 18, 2025 12:36

cmake: discard extra sections linking nacl_helper_bootstrap

f59e059

See d281e6a

illwieckz force-pushed the illwieckz/cmake branch from d807a6e to 3eee880 Compare June 9, 2026 17:12

illwieckz force-pushed the illwieckz/cmake branch from 3eee880 to f59e059 Compare June 19, 2026 00:04

illwieckz closed this Jun 21, 2026

illwieckz force-pushed the master branch from d281e6a to bae85fa Compare June 21, 2026 23:10

illwieckz mentioned this pull request Jun 21, 2026

CMake plumbing to build loader (2) #14

Open

illwieckz changed the title ~~Write a CMakeLists.txt to build the NaCl loader~~ CMake plumbing for the loader Jun 21, 2026

illwieckz changed the title ~~CMake plumbing for the loader~~ CMake plumbing to build loader Jun 22, 2026

Conversation

illwieckz commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Apr 7, 2025

Uh oh!

illwieckz commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Apr 7, 2025

Uh oh!

illwieckz commented Apr 7, 2025

Uh oh!

illwieckz commented Apr 7, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

slipher commented Apr 7, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025

Uh oh!

illwieckz commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Apr 8, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

illwieckz commented Jun 9, 2026

Uh oh!

illwieckz commented Jun 19, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

illwieckz commented Apr 7, 2025 •

edited

Loading

illwieckz commented Apr 7, 2025 •

edited

Loading

illwieckz commented Apr 7, 2025 •

edited

Loading

illwieckz commented Apr 8, 2025 •

edited

Loading

illwieckz commented Apr 8, 2025 •

edited

Loading