Is it correct, that from pepper 18 onwards, I dont need the scons build system in order to compile, but rather use gcc(nacl-versions) and makefiles?
Also, is it correct that the generated .nexe files will run on any platforms webserver, not just on the platform it was compiled on? So for example, the native code module is developed and compiled under mac os, and generates a 32bit and a 64bit nexe file. The webserver I will load this module on runs on linux, and will still execute the modules in both 32bit and 64bit versions?
Build system for Native Client
No version of the Native Client SDK mandates a particular build system; it has been possible at any time to use SCons, GNU Make, CMake, or even just shell scripts. Put differently, the compilers and tools - which are based on gcc and the GNU toolchain - are independent of the build system the developer decides to use.
However, up to and including the Pepper version 17 of the Native Client SDK, the examples in the SDK came with build files for SCons, and SCons was included in the SDK. From Pepper 18 and onwards this is no longer the case. Instead the build files that are provided for the examples are Makefiles intended for GNU Make.
Also see the release notes for the Pepper 18 version of the SDK.
Cross-compiling
The tools provided in the SDK currently support the 32-bit x86 and 64-bit x86 architectures. The platform of the web server is not important because the Native Client module runs on the client (that is, in the browser). This means there are two systems to consider: the user's system and the developer's system.
On the user's system, when Chrome encounters a Native Client module in a page, it fetches the executable (.nexe file) that's appropriate for the browser on that client. Hence, if a user on 64-bit Windows visits the page, the 64-bit binary will be fetched; if the user is on a 32-bit Mac, the 32-bit binary is fetched. There are exceptions, which I'll treat separately below. Chrome determines the names of the 32-bit and 64-bit .nexes from the manifest file. See the Native Client SDK site (www.GoNaCl.com) for a description and an example of a manifest file
The developer can – and should - produce both 32-bit and 64-bit executables regardless of the operating system and architecture used for development. Running 'make' in the examples/ directory of Pepper 18 and looking at the commands issued is a convenient way of seeing how to do this. E.g., part of the 'make hello_world_glibc' output reads something like:
i686-nacl-gcc -o hello_world_x86_32.nexe hello_world.c -m32 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi
and
i686-nacl-gcc -o hello_world_x86_64.nexe hello_world.c -m64 -O0 -g -pthread -O0 -g -Wno-long-long -Wall -lppapi
The first line produces the 32-bit .nexe; the second line produces the 64-bit .nexe. The important flag is -m32/-m64, which specifies the architecture - always build both, so that client's on both 32-bit and 64-bit machines can use the app.
Longer term, only one deployment format will be needed, and ARM will be added as a directly supported architecture. See the Portable Native Client project for details.
Here is the specific matching of browser and client architecture to 32/64 bit:
So as a general rule Chrome fetches the .nexe that matches its own bit-age – except on 64-bit Windows where Chrome fetches the 64-bit .nexe despite being 32-bit itself.