Most of NaCl, including the trusted runtime and tests, is built using Scons. However, Chromium ignores NaCl‘s Scons build system and uses gn to build NaCl (in the same way as it ignores Webkit’s own build system). This is why there are *.gn and *.gni files in the NaCl tree, though the NaCl standalone build doesn‘t use them. These gn files cover NaCl’s trusted code but not tests.
On some systems, the code that is normally in sel_ldr is statically linked into the Chromium executable. (The Gyp build also has a target to build a standalone sel_ldr, but this is mainly for testing purposes.)
Linking sel_ldr into Chromium has some advantages: * It reduces version skew issues. * It makes it easier to run sel_ldr inside the sandbox. On Linux, sel_ldr can be launched by forking Chromium's Zygote process, which is already set up to be sandboxed. This can also reduce per-instance startup costs a little. * It makes it easier for sel_ldr to link to Chromium-specific code (e.g. code specific to the Chromium Linux sandbox).
However, there also some good reasons to build sel_ldr as a separate executable: * On Windows 64, sel_ldr needs to be a 64-bit executable, while Chromium itself is 32-bit, so they cannot be linked together. * On ARM, sel_ldr needs to get control early in the process startup in order to reserve the bottom chunk of address space. * Even on x86-32, address space is relatively limited, so it would be beneficial to avoid loading non-NaCl Chromium code into sel_ldr's address space.
| Platform | Chromium process | NaCl process | Outer sandbox supported? |
|---|---|---|---|
| Linux, x86-32 | 32-bit | 32-bit | yes(1) |
| Linux, x86-64 | 64-bit | 64-bit (currently)(2) | yes(1) |
| Linux, ARM | 32-bit | 32-bit | in principle, yes(1) |
| Windows, x86-32 | 32-bit | 32-bit | yes |
| Windows, x86-64 | 32-bit(3) | 64-bit | yes |
| Mac OS X, x86-32 | 32-bit | 32-bit | yes(4) |
| Mac OS X, x86-64 | ? | 32-bit? | yes(4) |
Native Client should not #include files from the “chrome” directory in the Chromium source tree. However, #including files from other directories (such as “base”) might be OK. For some background, see [issue 469] (http://code.google.com/p/nativeclient/issues/detail?id=469).