Native Client

Release Notes

This page provides notes for all releases of the Native Client SDK (including releases that have been or will be published subsequent to Pepper 16).

PNaCl in Chrome 30 Dev channel (01 Aug 2013)

  • Portable Native Client (PNaCl) is currently available for preview in Chrome 30 (currently in the Dev channel). Apps and sites built with PNaCl can run in Chrome 30 without an explicit flag.
  • See Introduction to Portable Native Client for information on developing for PNaCl. More documentation will be available soon.
  • Please note that the PNaCl bitcode ABI may still change before the official public release; if you're developing a PNaCl-based application, be sure to build your code with the latest version of the Native Client SDK.
  • Update: PNaCl is not enabled by default in beta or stable versions of M30.

PNaCl (15 May 2013)

  • Portable Native Client (PNaCl) is currently available for developer preview in Chrome 29 or higher.
  • To produce a PNaCl executable (.pexe) file, you must use the pnacl toolchain in the current pepper_canary bundle. Chrome 29 does not support .pexe files produced by earlier versions of the pnacl toolchain (that is, executables compiled with the pepper_28 bundle or earlier).
  • To run an application with a PNaCl module, you must launch Chrome 29 with the --enable-pnacl flag (for packaged apps), or the --enable-nacl flag (for other apps).
  • When you launch Chrome with the --enable-pnacl flag, Chrome loads a PNaCl translator in the background. Wait about a minute after you launch Chrome and check chrome://nacl to verify that the translator loaded.
  • PNaCl translators are currently available for 32-bit x86, 64-bit x86, and ARM architectures.
  • PNaCl applications must use the newlib C library (glibc and dynamic linking are not supported yet).
  • The intermediate representation (IR) format may change prior to the release of PNaCl. If so, you will need to recompile your application with the pnacl toolchain in a new SDK bundle.

Pepper 27 (12 April 2013)

The Pepper 27 bundle features a significant number of new libraries that have been incorporated directly into the SDK.

Libraries

  • A number of libraries from the naclports project have been incorporated directly into the Native Client SDK. These libraries include:
    • image encoding/decoding: jpeg, tiff, png, webp
    • multimedia: openal, freealut, ogg, vorbis
    • XML parsing: tinyxml, xml2
    • miscellaneous: zlib (general purpose compression), freetype (font rendering), lua (Lua interpreter)
    The libraries are located in ports/lib, and the header files are in ports/include.
  • The httpfs filesystem in the nacl_io library now caches content in memory by default; this improves performance considerably.
  • For applications compiled with a glibc toolchain, dlopen() can now be used to open shared libraries that are not specified in an application's Native Client manifest (.nmf) file. This allows applications, for example, to download a shared object and then use dlopen() to access the shared object. The dlopen example has been modified to demonstrate this functionality: reverse.cc is built into a shared object (.so) file, which is downloaded and opened using an httpfs mount.

Examples

  • Each example now has a single index.html file, instead of multiple HTML files corresponding to NaCl modules built using different toolchains and configurations. By default, most examples are built using one toolchain (newlib) and one configuration (Debug). If you build an example using multiple toolchains or configurations, you can specify which version to run in Chrome using the query parameters tc and config. For example, assuming you are serving an example from the local server localhost:5103, you can run a version of the example built with the glibc toolchain in the Release configuration by specifying the following URL in Chrome: http://localhost:5103/index.html?tc=glibc&config=Release. For additional information about how different NaCl modules are loaded into index.html, see the common.js file in each example.

Build tools and toolchains

  • Common makefiles, including tools/common.mk, can now handle source files located outside of an application's root directory. For example, a Makefile for an application can specify a source file to compile such as ../../some/other/place.cpp.

Pepper 26 (29 March 2013)

The Pepper 26 bundle includes a new HTTP filesystem type in the nacl_mounts library (which has been renamed nacl_io), changes to the example Makefiles, a simple new 3D example, and a threaded file IO example.

Build tools and toolchains

  • Makefiles have been changed significantly:
    • Build commands are now specified in a number of common files (tools/*.mk), which are included in the Makefiles in the examples.
    • By default, make displays a simplified list of build steps (e.g., CC newlib/Debug/hello_world_x86_32.o) rather than the actual build commands. To see the actual build commands, run make V=1.
    • By default, most examples are built using one toolchain (newlib) and one configuration (Debug). To build an example using a different toolchain or configuration, run make with the parameters TOOLCHAIN=<x> or CONFIG=<y>. You can also run make all_versions to build an example with all toolchains.
  • Header files have been moved out of the toolchains. All toolchains now share the same set of header files as host builds. Previously host and NaCl builds used different headers, which could cause build problems.

Libraries

  • The nacl_mounts library has been renamed nacl_io, and has been expanded with a new type of mount, httpfs, which can be used to read URLs via HTTP. For details see include/nacl_io/nacl_io.h, as well as the hello_nacl_io example.

Examples

  • A new example, hello_world_instance3d, has been added to demonstrate a simplified 3D app.
  • The file_io example has been rewritten to do all file operations on a thread. The example demonstrates how to use the MessageLoop API and blocking callbacks on a thread.

General

  • Old bundles (pepper_20 and earlier) have been removed from the Native Client SDK Manifest, and will no longer be updated by the naclsdk command.

Pepper 25 (21 December 2012)

The Pepper 25 bundle features an ARM toolchain to build Native Client modules for ARM devices, two new Pepper APIs (including the MessageLoop API, which lets you make Pepper calls on background threads), two new libraries (nacl_mounts, which provides a virtual file system that you can use with standard C file operations, and ppapi_main, which lets you implement a Native Client module using a simple ppapi_main function), and two new examples that demonstrate how to use the nacl_mounts and ppapi_main libraries.

Build tools and toolchains

  • The SDK includes a new toolchain to build Native Client executables (.nexe files) for ARM devices.
    • Currently the ARM toolchain can only be used to compile modules that use the newlib C library. You cannot use the ARM toolchain to compile modules that use the glibc library.
    • The ARM toolchain is in the directory pepper_25/toolchain/linux_arm_newlib. The bin subdirectory contains the compiler (arm-nacl-gcc), the linker (arm-nacl-g++), and the other tools in the toolchain.
    • Take a look at the hello_world example to see how to use the ARM toolchain. Go to examples/hello_world and run make. When the build finishes, the newlib/Debug and newlib/Release subdirectories will contain .nexe files for the x86-32, x86-64, and ARM target architecutes, and a Native Client manifest (.nmf file) that references those three .nexe files.
  • The simple web server included in the SDK, httpd.py, has been moved from the examples/ directory to the tools/ directory. On Windows, you can run httpd.cmd (in the examples/ directory) to start the server.

PPAPI

Pepper 25 includes two new APIs:

  • The Console API lets your module log messages to the JavaScript console in the Chrome browser.
  • The MessageLoop API lets your module make PPAPI calls on a background thread. Once you've created a message loop resource, attached it to a thread, and run it, you can post work to the thread, including completion callbacks for asynchronous operations. For a C++ example of how to use the MessageLoop API, see pepper_25/include/ppapi/utility/threading/simple_thread.h. Note that you cannot make asynchronous PPAPI calls on a background thread without creating and using a message loop.

Libraries

The SDK includes two new libraries:

  • The nacl_mounts library provides a virtual file system that your module can "mount" in a given directory tree. The file system can be one of several types:
    • "memfs" is an in-memory file system,
    • "dev" is a file system with various utility nodes (e.g., /dev/null, /dev/console[0-3], /dev/tty), and
    • "html5fs" is a persistent file system.
    Once you've mounted a file system in your module, you can use standard C library file operations: fopen, fread, fwrite, fseek, and fclose. How those operations are performed depends on the type of file system (e.g., for html5fs, the operations are performed using the Pepper FileIO API). For a list of the types of file systems you can mount, see include/nacl_mounts/nacl_mounts.h. For an example of how to use nacl_mounts, see examples/hello_nacl_mounts. Note that html5fs is subject to the same constraints as persistent local file IO in Chrome (for example, prior to using an html5fs file system, you must enable local file IO).
  • The ppapi_main library simplifies the creation of a NaCl module by providing a familiar C programming environment. With this library, your module can have a simple entry point called ppapi_main(), which is similar to the standard C main() function, complete with argc and argv[] parameters. Your module can also use standard C functions such as printf(), fopen(), and fwrite(). For details see include/ppapi_main/ppapi_main.h. For an example of how to use ppapi_main, see examples/hello_world_stdio.

Header files for the new libraries are in the include/ directory, source files are in the src/ directory, and compiled libraries are in the lib/ directory.

Examples

  • The SDK includes two new examples:
    • hello_nacl_mounts illustrates how to use standard C library file operations in a Native Client module through the use of the nacl_mounts library.
    • hello_world_stdio illustrates how to implement a Native Client module with a ppapi_main() function, and how to write to STDOUT and STDERR in a module, through the use of the nacl_mounts and ppapi_main libraries. This example makes it easy for new users to get started with Native Client by letting them start making changes in a familiar C environment.
  • With a few exceptions, the Makefile for each example now builds the following versions of each example:
    • glibc toolchain: 32-bit and 64-bit .nexes for the x86 target architecture
    • newlib toolchain: 32-bit and 64-bit .nexes for the x86 target architecture, and ARM .nexe for the ARM architecture
    • pnacl toolchain: .pexe (which is subsequently tranlsated to .nexes for the x86-32, x86-64, and ARM architectures)
    • hosted toolchain: .so or .dll (to be executed as a Pepper plug-in in Chrome)
    Additionally, each version is built in both a Debug and a Release configuration.
  • The Makefile for each example includes two new targets: make RUN and make LAUNCH. These targets, which are interchangeable, launch a local server and an instance of Chrome to run an example. When the instance of Chrome is closed, the local server is shut down as well.
  • The hello_world_stdio example includes a simplified Makefile that only lists source dependencies, and invokes the build rules in a separate file (common.mk).

Pepper 24 (5 December 2012)

The Pepper 24 bundle features a new, experimental toolchain called PNaCl (short for "Portable Native Client"), a new library (pthreads-win32) for the Windows SDK, and an expanded list of attributes for Pepper 3D contexts that lets applications specify a GPU preference for low power or performance.

Build tools and toolchains

  • The SDK includes a new, experimental toolchain called PNaCl (pronounced "pinnacle"). The PNaCl toolchain produces architecture-independent executable files (.pexe files). Chrome doesn't yet support .pexe files directly, but if you want to experiment with this early preview of PNaCl, the toolchain includes a tool to translate .pexe files into architecture-specific .nexe files. Take a look at the hello_world example to see how to build a .pexe file and translate it into multiple .nexe files. Note that PNaCl is currently restricted to the newlib C standard library – if your application uses glibc, you can't build it with PNaCl.
  • The create_nmf.py script uses ELF headers (rather than file names) to determine the architecture of .nexe files. That means you can change the names of your .nexe files and create_nmf.py will still be able to generate the appropriate Native Client manifest file for your application.

Examples

  • The SDK examples now build with four toolchains: the glibc and newlib toolchains, the experimental PNaCl toolchain, and the hosted toolchain on your development machine. Within each toolchain build, each example also builds both a debug and a release version.
  • The example Makefiles use dependency (.d) files to enable incremental builds.
  • The pong example has been cleaned up and modified to run more smoothly. The drawing function is now set up as the Flush() callback, which allows 2D drawing to occur as quickly as possible.

PPAPI

  • When creating a 3D rendering context, the attribute list for the context can specify whether to prefer low power or performance for the GPU. Contexts with a low power preference may be created on an integrated GPU; contexts with a performance preference may be created on a discrete GPU.

Windows SDK

  • The Windows SDK includes the pthreads-win32 library to assist in porting from win32 code. You can use this library when developing your module as a Pepper plug-in (.dll). See pepper_24/include/win/pthread.h and pepper_24/src/pthread/README for additional information.
  • The update utility naclsdk.bat works when it is run from a path with spaces.

Pepper 23 (15 October 2012)

The Pepper 23 bundle includes support for the nacl-gdb debugger on Mac and 32-bit Windows, resources to enable hosted development on Linux, and changes to make the SDK examples compliant with version 2 of the Chrome Web Store manifest file format.

Tools

  • The nacl-gdb debugger now works on all systems (Mac, Windows, and Linux).
  • The output of the SDK update utility has been simplified. When you run the command naclsdk list, the utility displays one line for each available bundle, annotated with an "I" if the bundle is already installed on your system, and a "*" if the bundle has an update available. To see full information about a bundle, use the command naclsdk info <bundle> (for example, naclsdk info pepper_16).

Linux SDK

  • Developers using the Linux SDK now have resources, including pre-built libraries and example Makefiles, that make it easier to build a module as a Pepper plugin (sometimes called a "trusted" or "in-process" plugin) using the native C/C++ compiler on their development system. In essence this makes developing a Native Client module a two-step process:
    1. Build the module into a shared library (.so file) using your system's C/C++ compiler. Test and debug the .so file using the tools in your normal development environment.
    2. Build the module into a .nexe file using the compiler from one of the Native Client toolchains in the SDK (nacl-gcc or nacl-g++). Test and debug the .nexe file using nacl-gdb.
    This two step development process has many benefits—in particular, you can use the compilers, debuggers, profilers, and other tools that you're already familiar with. But there are a few potential issues to keep in mind:
    • Chrome uses different threading models for trusted plugins and Native Client modules.
    • Certain operations such as platform-specific library calls and system calls may succeed during trusted development, but fail in Native Client.
    Here are the resources you can use to build your module into a Pepper plugin:
    • header files are in pepper_23/include
    • source files are in pepper_23/src
    • pre-built libraries are in pepper_23/lib
    You can now build and run most of the examples in the SDK as Pepper plugins.
    • Look at the example Makefiles or run make in the example directories to see the commands and flags used to build modules as Pepper plugins.
    • Run make LAUNCH in the example directories to see how to use the --register-pepper-plugins argument to load a Pepper plugin in Chrome. Note that you must set the CHROME_PATH environment variable and start a local server prior to running this command.

Examples

  • On Linux and Windows systems, most of the examples now build with three toolchains: the Native Client glibc and newlib toolchains, and the native toolchain on the host system. Modules built with the native toolchain on the host system can only run as Pepper plugins.
  • All examples in the SDK now comply with version 2 of the Chrome Web Store manifest file format. By default, applications that use version 2 of the manifest file format apply a strict content security policy, which includes a restriction against inline JavaScript. This restriction prohibits both inline <script> blocks and inline event handlers (e.g., <button onclick="...">). See Manifest Version for a list of changes between version 1 and version 2 of the manifest file format, and a support schedule for applications that use version 1.

PPAPI

Pepper 22 (22 August 2012)

The Pepper 22 bundle includes a command-line debugger, resources to enable hosted development on Windows, and changes to the example Makefiles (each example now builds both a debug and a release version).

Tools

  • The SDK now includes a command-line debugger that you can use to debug Native Client modules. See Debugging with nacl-gdb for instructions on how to use this debugger. For now, nacl-gdb only works on 64-bit Windows, 64-bit Linux, and 32-bit Linux systems. Support for Mac and 32-bit Windows systems will be added soon.

Windows SDK

  • Developers using the Windows SDK can now build a module as a Pepper plugin (sometimes called a "trusted" or "in-process" plugin) using the native C/C++ compiler on their development system. In essence this makes developing a Native Client module a two-step process:
    1. Build the module into a DLL using your system's C/C++ compiler. Test and debug the DLL using the tools in your normal development environment.
    2. Build the module into a .nexe using the compiler from one of the Native Client toolchains in the SDK (nacl-gcc or nacl-g++). Test and debug the .nexe using nacl-gdb.
    This two step development process has many benefits—in particular, you can use the compilers, debuggers, profilers, and other tools that you're already familiar with. But there are a few potential issues to keep in mind:
    • Some libraries that are commonly used with Native Client may not build easily on Windows.
    • You may need to put in extra effort to get source code to compile with multiple compilers, e.g., Microsoft Visual Studio and GCC.
    • Chrome uses different threading models for trusted plugins and Native Client modules.
    • Certain operations such as platform-specific library calls and system calls may succeed during trusted development, but fail in Native Client.
    Here are the resources you can use to build your module into a DLL:
    • header files are in pepper_22\include
    • source files are in pepper_22\src
    • pre-built libraries are in pepper_22\lib
  • A Visual Studio add-in will be available in the near future with configurations that include platforms for both Pepper plugins and NaCl modules.

Note: It's also possible to build a module as a trusted plugin on Mac and Linux systems, but doing so requires more work because the SDK does not yet include the above resources (library source files and pre-built libraries) for Mac and Linux systems. To build and debug a trusted plugin on Mac and Linux systems, you need to get the Chromium code and then follow the Mac instructions or Linux instructions. In the future, the SDK will include resources for hosted development on Mac and Linux as well as Windows.

Examples

  • Each example in the SDK now builds both a debug and a release version. As before, most examples also build newlib and glibc versions, which means that there are now four versions for each example. Take a look at the Makefiles in the examples to see the compiler flags that are used for debug and release versions. For a description of those flags, see Compile flags for different development scenarios.
  • Comments have been added to common.js, which is used in all the examples. The JavaScript in common.js inserts an <embed> element that loads the NaCl module in each example's web page, attaches event listeners to monitor the loading of the module, and implements handleMessage() to respond to messages sent from the NaCl module to the JavaScript side of the application.

PPAPI

Canary bundle (29 June 2012)

The Native Client SDK includes a new bundle called pepper_canary. The pepper_canary bundle will always be the newest, bleeding-edge bundle available. Currently the pepper_canary bundle has the toolchains, libraries, and examples for Pepper/Chrome 22. As this bundle stabilizes, it will be renamed pepper_22, and the pepper_canary bundle will be overwritten with the tool set for Pepper/Chrome 23.

You may want to use the pepper_canary bundle to test the newest Pepper APIs or SDK tools that are not yet available in regular Pepper bundles. For typical development, however, you should use a bundle for a specific version of Pepper (e.g., pepper_20, pepper_21, etc.), and do controlled upgrades from bundle to bundle as their stability levels progress.

Pepper 21 (29 June 2012)

The Pepper 21 bundle includes a script that can be used to generate Native Client manifest (.nmf) files for applications that are built with either the newlib or glibc toolchains, changes to the example Makefiles (most SDK examples are now built with both the newlib and glibc toolchains), and a couple of new examples (file_io and hello_world_gles).

Tools

  • You can now use the create_nmf.py script to generate Native Client manifest (.mnf) files for applications that use either the newlib or glibc toolchains. The script is in the tools directory. Run "python create_nmf.py --help" to see a list of command-line options. Look at examples/hello_world/Makefile to see how to use the script to generate a manifest file for either toolchain.

Examples

  • The Makefiles for the SDK examples now build the examples using both the newlib and glibc toolchains. With a few exceptions (listed in the following bullet), running "make" in each example's directory does the following:
    • creates a subdirectory called newlib;
    • builds 32- and 64-bit .nexes using the newlib toolchain;
    • generates a Native Client manifest (.nmf) file for the newlib version of the example;
    • creates a subdirectory called glibc;
    • builds 32- and 64-bit .nexes using the glibc toolchain; and
    • generates a Native Client manifest (.nmf) file for the glibc version of the example.
  • The following examples are built using only one toolchain:
    • tumbler (uses newlib)
    • debugging (uses newlib)
    • dlopen (uses glibc)
  • Running "make" in the top-level examples directory builds all versions of each example.
  • The index.html page for each example redirects to index_newlib.html if the example is built with the newlib toolchain, or to index_glibc.html if the example is only built with the glibc toolchain. For examples that are built with both toolchains, you can run either the newlib or glibc version of an example by navigating directly to one of the following URLs (assuming you are running a local server):
    • http://localhost:5103/<example>/index_newlib.html
    • http://localhost:5103/<example>/index_glibc.html
  • The index file(s) for each example (index_newlib.html and/or index_glibc.html) do not contain an <embed> element for the Native Client module. The <embed> element is created dynamically and inserted in the web page by JavaScript (in the file common.js).
  • The SDK includes the following new examples:
    • file_io: demonstrates how to save, load, and delete files from the persistent file store using the Pepper FileIO API
    • hello_world_gles: demonstrates how to create a rotating 3D cube using the Pepper Graphics3D API, and how to load assets using the Pepper URLLoader API (this example is written in C and is simpler than the tumbler example)
  • The following examples have been modified:
    • hello_world_newlib and hello_world_glibc have been merged into hello_world. As with most examples in the SDK, hello_world is built using both the newlib and the glibc toolchains.
    • The mouselock example allows the mouse to be locked (hidden) in either fullscreen mode or normal (non-fullscreen) mode. When you run the example, click on the grey box (the rectangle controlled by the Native Client module), press Esc to exit fullscreen mode, and then press Enter to toggle mouse lock on/off.

Pepper 20 (29 May 2012)

The Pepper 20 bundle/platform includes the Pepper MouseCursor API, which can be used to modify the mouse cursor, and a new example, file_histogram, which demonstrates how to enable a user to provide one or more local files to a Native Client application.

MouseCursor API

You can use the MouseCursor API to set the mouse cursor to a system-defined cursor, a custom cursor, or no cursor (i.e., to hide the mouse cursor).

file_histogram example

The file_histogram example (in the directory pepper_20/examples/file_histogram) demonstrates use of the HTML5 File API and the Pepper VarArrayBuffer API to enable a user to provide one or more local files to a Native Client application. The example uses the HTML5 File API to read one or more local files into a JavaScript ArrayBuffer. The user can specify which files to read using either a dialog box or drag-and-drop. (For additional information about the File API, see Reading Files in JavaScript Using the File APIs.) The JavaScript code in the file_histogram example uses postMessage() to send the contents of each file to the Native Client module. The Native Client module copies the contents of the ArrayBuffer into its address space using the Pepper VarArrayBuffer API, and then draws a histogram representation of the file contents using the Pepper Graphics2D API.

Pepper 19 (2 April 2012)

The Pepper 19 bundle/platform includes the Pepper Gamepad API, which enables input events from gamepad controllers, and a new debugging example that demonstrates how to generate a stack trace for a Native Client module. (The debugging example is a developer preview; the signal handlers and techniques demonstrated in the example should not be used in production.)

Gamepad API

  • The Gamepad interface is now stable and can be used in production.
  • While the Gamepad interface is included in the Pepper C API, C++ classes for the interface are not available yet.
  • For an example of how to use the Gamepad interface see the application in the directory pepper_19/examples/gamepad.
  • For security reasons, gamepads are not connected automatically in NaCl applications—the user must press a button on a gamepad in order to connect the gamepad and display the user interface.

Debugging example

  • The new debugging example is in the directory pepper_19/examples/debugging. For this example to work, you must launch Chrome with special command line arguments and environment variables. Here is how to run the example:
    1. In one terminal window:
      1. Set the environment variable CHROME_PATH to the fully-qualified path of your Chrome executable.
      2. Go to the directory pepper_19/examples/debugging and execute the command: make RUN
        This starts a local web server using the default port 5103.
    2. In a second terminal window:
      1. Set the environment variable CHROME_PATH to the fully-qualified path of your Chrome executable.
      2. Go to the directory pepper_19/examples/debugging and execute the command: make TRACE
        This launches Chrome with the required arguments and points it to the debugging example on the local server you started in the first step (http://localhost:5103/debugging.html).

    Note: The debugging example relies on untrusted hardware signal handling, which is an alpha feature that may change without notice. The untrusted signal handlers and the techniques demonstrated in the debugging example are provided as a developer preview only and should not be used in production.

Pepper 18 (5 March 2012)

The Pepper 18 bundle/platform includes these new features:

  • New Pepper APIs:
    • WebSocket: provides bi-directional, full-duplex, communication over a single TCP socket
    • ArrayBuffer: enables interaction with JavaScript ArrayBuffers
    • View: allows you to get the state of the view for a module instance
    • Gamepad: enables input events from gamepad controllers
      Note: The Gamepad interface is a dev interface—we've provided it so that you can start developing with it, but you should not use it in production yet. We'll be shipping the stable interface shortly.
  • Makefiles:
    • The SCons build tool and build scripts have been removed from the SDK and replaced with Makefiles. Makefiles have been kept simple so that they are easy to understand, use, and modify. Glance through or run the Makefiles to determine the commands that are needed to build an application, then plug those commands into your own build system if you prefer.
  • New examples:
    • a new, simpler "Hello, World" example in two flavors: one example is built with newlib and the other is built with glibc; the latter example, hello_world_glibc, uses the glibc toolchain and demonstrates how to generate the more complex Native Client manifest file (.nmf) needed to load shared libraries
    • dlopen: demonstrates how to build dynamic libraries and how to open and use such libraries at runtime
    • gamepad: demonstrates how to use the Pepper Gamepad API
    • index.html: a more informative index.html file in the examples/ directory describes each example and defines its expected behavior

Bundle installation

  • The pepper_18 bundle is currently a dev bundle; as such the SDK update utility will not download the bundle by default. To download the bundle, run the command 'naclsdk update pepper_18 --force'.
  • On Windows systems, bundles are now installed using tarballs instead of installers. If you want to delete a bundle you can simply delete the corresponding directory.

Build tools and toolchains

  • The SCons build tool and build scripts have been removed from the SDK and replaced with Makefiles.
    • Execute the command 'make' in any example subdirectory to build the 32-bit and 64-bit .nexe files for that example. For examples that use glibc, the 'make' command also invokes a script to programmatically generate a manifest file (.nmf). (Manifest files for newlib examples are very simple and are written manually.)
    • Execute the command 'make RUN' in any example subdirectory to build that example and launch a web server to run the example.
    • Execute the command 'make RUN' in the examples/ directory to build and run all the examples.
    • Scan through any Makefile to see the compile/link commands and the flags that are used to build the examples.
  • On the Mac, you need to install 'make' on your system before you can build and run the examples. One easy way to get 'make' (along with several other useful tools) is to install Xcode Developer Tools.
  • The two toolchains in the SDK have been renamed with a suffix to identify which implementation of libc is used in each toolchain. For example, on the Windows platform, the toolchains are named win_x86_newlib and win_x86_glibc.

SDK examples

  • Two new, basic examples have been added: hello_world_newlib and hellow_world_glibc. These examples simply load a Native Client module that triggers a JavaScript alert. Each example includes a single C file, and a Makefile with a single compile/link command.
  • The hello_world_glibc example uses the glibc toolchain and demonstrates how to generate the Native Client manifest file (.nmf) needed to load shared libraries. The manifest file is generated automatically during the build process by scanning the application for dependencies.
  • The original hello_world example has been renamed hello_world_interactive. This C++ example includes multiple files, more complicated interaction between JavaScript and the Native Client module, and a more complex Makefile.
  • The dlopen example shows how to compile a simple shared library, along with a .nexe, and how to properly generate the .nmf file for an application that uses glibc. The example also demonstrates how to use a worker thread to load a shared library.
  • The gamepad example shows how to use the Pepper Gamepad API. The Gamepad API, defined in toolchain/platform_libc/x86_64-nacl/include/ppapi/c/dev/ppb_gamepad_dev.h, is a dev interface and is subject to change. You should not use the Gamepad API in production until the interface is out of dev and in stable.
  • The performance of the pong example has been improved.
  • The file examples/index.html has been rewritten to describe each example and its expected behavior.

General notes

  • The project_templates directory and the init_project.py script have been removed from the SDK. To start a new project, simply copy the code and the Makefile from one the SDK examples.
  • A number of additional directories in the SDK have also been cleaned up or removed.

Pepper 17 (3 January 2012)

The Pepper 17 bundle/platform includes a new example, multithreaded_input_events, and a number of bug fixes.

Pepper 16 (13 December 2011)

The Pepper 16 bundle/platform includes these new features:

  • the Pepper Fullscreen API
  • the Pepper Mouse Lock API

General notes

  • There are some performance issues with mouse lock on Microsoft Windows. These issues are resolved in Chrome/Pepper 17.

Pepper 15 (12 October 2011)

The Pepper 15 bundle/platform includes these new features:

  • the Pepper 3D API (including support for OpenGL ES 2.0)
  • a developer preview of the glibc toolchain (including support for shared objects)
  • improved malloc() performance

General notes

SDK 1.0 (12 October 2011)

This release of the Native Client SDK features substantial changes to the way the SDK is downloaded and updated.

  • The SDK is now comprised of multiple bundles that let you compile Native Client modules using different versions of the Pepper API (e.g., Pepper 14 or Pepper 15).
  • Native Client modules compiled using a particular Pepper platform will work in corresponding versions of Chrome and higher. For example, a module compiled using the Pepper 14 platform will work in Chrome 14 and higher. You can use code like check_browser.js to test for a minimum Chrome version in your application.
  • To compile a module for a specific platform (e.g., Pepper 14 or Pepper 15), you must compile the module within the directory for that platform (pepper_14 or pepper_15). This is a temporary requirement; in the future you will be able to use the --platform flag to compile for different platforms.
  • A new utility, naclsdk, lets you download new bundles that are available, as well as new versions of existing bundles. See the Download page for instructions on how to use this utility.
  • To use the SCons build scripts included in the SDK, you must have the NACL_SDK_ROOT variable set in your shell environment. For example, on Windows, set %NACL_SDK_ROOT% to the path where you installed the contents of nacl_sdk.zip.

SDK 0.5 (28 July 2011)

General notes

  • Starting with Chrome 14, Native Client has a stable application binary interface (ABI). That means there is no longer a need to match versions of Chrome with versions of the SDK. Applications compiled with version 0.5 of the SDK will work in Chrome 14 and future versions of Chrome. Applications compiled with version 0.5 of the SDK will not work in Chrome 13 or earlier versions of Chrome.
  • Applications compiled with earlier versions of the SDK will not work in Chrome 14 or future versions of Chrome.

Toolchain changes

  • The names of the tools in the compiler toolchain are changing to conform with gcc naming standards. The table below lists the old and new prefixes in the tool names:
    Old prefix New prefix
    nacl- i686-nacl-
    nacl64- x86_64-nacl-

    Here are a couple of examples of the tool name changes:

    • nacl-gcci686-nacl-gcc
    • nacl64-gccx86_64-nacl-gcc

    The old tool names will be removed in a future release, but they are still available for the time being. The new names may be particularly helpful with tools like autoconf.

  • The ncval and sel_ldr tools have been renamed as follows:
    Old name New name
    nacl-ncval ncval_x86_32
    nacl-sel_ldr sel_ldr_x86_32
    nacl64-ncval ncval_x86_64
    nacl64-sel_ldr sel_ldr_x86_64

    ncval and sel_ldr are different than the rest of the tools in the bin directory, in that the platform designation indicates the platform on which you are running the tools, rather than the target platform for which you are compiling. For additional information on ncval and sel_ldr, see the Testing section of the Building page.

API changes

  • Pepper now includes file I/O. The new file I/O API provides feature parity with HTML5 file access, allowing Native Client applications to read from and write to local, persistent file stores. Documentation is forthcoming, but if you want to start using the file I/O API now, look at file_system.h, file_ref.h, and file_io.h in the SDK directory toolchain/platform/nacl64/include/ppapi/cpp. Note that the default file size quota is 0; you must increase this quota in order to create and write files with the file I/O API. To increase the quota, create a Chrome Web Store app and specify unlimitedStorage in the app's permissions (declared in the app's Web Store manifest file). For testing prior to deployment to the Chrome Web Store, you can also run Chrome with the --unlimited-quota-for-files flag.
  • The interface for handling input events has been changed in order to accommodate future features. The specific changes for C++ and C are described below. Note that you must register your module instance to receive classes of input events – by default, no events are sent.
    • For C++: The old input event C struct, PP_InputEvent, has been replaced with a Resource object, InputEvent, and pp::Instance::HandleInputEvent now accepts an InputEvent object. For more information see the comments for pp::InputEvent in toolchain/platform/nacl64/include/ppapi/cpp/input_event.h.
    • For C: PPP_Instance.HandleInputEvent has been removed. See PPB_InputEvent and PPP_InputEvent (in ppapi/c/ppb_input_event.h and ppp_input_event.h) for the new interfaces.
  • The value PP_ERROR_WOULDBLOCK has been removed from toolchain/platform/nacl64/include/ppapi/c/pp_errors.h. Pepper functions now return PP_OK_COMPLETIONPENDING instead when they are running asynchronously.
  • A new flags field has been added to the PP_CompletionCallback struct to control how non-NULL callbacks are scheduled by asynchronous Pepper methods. The new default behavior is to always force callback invocation, regardless of whether Pepper methods return success or error. To trigger the original behavior where a Pepper method could complete an operation synchronously and ignore the callback, you must now set the PP_COMPLETIONCALLBACK_FLAG_OPTIONAL flag, or use PP_MakeOptionalCompletionCallback(). For more information see the PP_CompletionCallback_Flag enum in toolchain/platform/nacl64/include/ppapi/c/pp_completion_callback.h.
  • Synchronous scripting functions have been removed from Pepper. Modules must use the PostMessage asynchronous API to communicate with JavaScript. The SDK Examples and Tutorial demonstrate use of the PostMessage ansynchronous API. For additional information see the API changes described in the release notes for version 0.4 of the SDK.
  • The HandleInputEvent and GetInstanceObject method pointers have been removed from the struct PPP_Instance in toolchain/platform/nacl64/include/ppapi/c/ppp_instance.h. These changes are related to the new interface for handling input events, and to the removal of synchronous scripting functions, as described above. Any C module that populates the PPP_Instance struct needs to remove code that references these method pointers.
  • The manifest file format has changed. Existing manifest files that look like this:
    // old manifest file format -- DO NOT USE THIS FORMAT
    {
    "nexes": {
    "x86-32": "foo-32.nexe",
    "x86-64": "foo-64.nexe",
    "arm": "foo-arm.nexe"
    }
    }
    need to be changed to this:
    // new manifest file format -- USE THIS FORMAT
    {
    "program": {
    "x86-32": {"url": "foo-32.nexe"},
    "x86-64": {"url": "foo-64.nexe"},
    "arm": {"url": "foo-arm.nexe"}
    }
    }
    For a full description of the manifest file format, see the NaCl manifest specification.

Known issues

  • Native Client has been disabled in Chrome 14 for Linux 32-bit systems. For more information see Issue 2157 Developers on 32-bit Linux systems should try Chrome 15 beta when it's available.
  • Some versions of OS X have a bug that can cause the kernel to crash when running Native Client applications. This bug can occur if all of the following apply:
    • You are using OS X version 10.6.7 or earlier.
    • You are using 64-bit kernel version 10.7.0 or earlier.

    To find out which kernel you're using, type 'uname -a' in a terminal window. If you see i386, you're using a 32-bit kernel; if you see x86_64, you're using a 64-bit kernel. Note that the kernel version number is different than the OS X version number.

    Apple has fixed the kernel bug in the official release of OS X 10.6.8 and higher, including OS X 10.7 (Lion). Thus, Native Client is enabled on those versions of OS X. To find out if you're running the official release of OS X 10.7, type 'uname -a' in a terminal window – the output should include "xnu-1699.22.73".

    Native Client has been disabled for official releases of OS X 10.6.7 and earlier running 64-bit kernel version 10.7.0 or earlier. Native Client applications will not work on machines running those OS/kernel combinations until you allow Software Update to apply the most recent OS fixes, which upgrades the 64-bit kernel to version 10.8.0 or later.

    Native Client has not been disabled for developer releases of OS X. If you're using a developer release of OS X (including a developer release of OS X 10.7), you may be using an older version of the 64-bit kernel that still has the bug. Running Native Client applications on such machines may cause the kernel to crash. For additional information on when Native Client triggers this MacOS kernel bug see Issue 1712.

  • For a list of open issues, see the Native Client issue tracker and the Chrome issue tracker.

Addendum

  • The Pepper file I/O API does not work when Chrome is in incognito mode. (The same is true for the HTML5 FileSystem API.) See Chromium bug 93417 for additional information. [6 Sept. 2011]

SDK 0.4 (20 June 2011)


This release of the Native Client SDK features substantial changes to the toolchain and build (namely the use of SCons instead of Gnu Make to build and run SDK examples and templates) and API changes (such as the PostMessage asynchronous API replacing the scripting interface). Following is a list of all changes in this release:

Toolchain and build changes

  • The SDK now uses SCons instead of Gnu Make for building the examples and generating new project templates. SCons requires Python on your system (see next bullet).
  • Python version 2.5 is required (2.6 and 2.7 work too) to build the examples and generate new project templates (Python 3.x is not supported).
    • MacOS X: MacOS X 10.6 (required to use the tools) comes with Python 2.5 and 2.6 pre-installed.
    • Linux: Usually comes with with Python 2.5 or higher pre-installed. Ensure your Linux system has this version or higher by running python -V. If your version is unsupported by the SDK, refer to your distribution's documentation on how to install a compatible version of python.
    • Microsoft Windows:
      1. Visit python.org/download.
      2. Click the "Python xxx Windows Installer" link. Where xxx is a 2.x version of Python.
      3. Run the installer.
  • Experimental support for Valgrind is now available for 64-bit Linux systems. Refer to the README file in the third_party/valgrind directory of the SDK for further information.
  • Cygwin is no longer part of the Microsoft Windows installer. Therefore, commands such as make and tar will no longer be available.

API changes

  • The PostMessage asynchronous API replaces the scripting interface as a way to communicate with the DOM. The SDK Examples and Tutorial in this release cover these new features. Synchronous scripting functions are planned to be removed in the next release of the SDK. Developers should use this release to migrate to the PostMessage-based asynchronous scripting interface.

    The following changes are planned for the C interfaces in the next release of the SDK. We recommend switching to the new alternatives listed at this point.

    • PPB_Var_Deprecated will not be available. Use PPB_Var, PPB_Messaging, and PPP_Messaging instead.
    • PPP_Class_Deprecated will not be available. Use PPB_Messaging and PPP_Messaging instead.
    • PPB_Instance will no longer have GetWindowObject, GetOwnerElementObject, or ExecuteScript. Use PPB_Messaging and PPP_Messaging instead.
    • PPP_Instance will no longer have GetInstanceObject. Use PPB_Messaging and PPP_Messaging instead.

    The following changes will likely happen for C++ in the next release of the SDK:

    • pp::deprecated::ScriptableObject will not be available. (Use PostMessage and HandleMessage on pp::Instance instead).
    • pp::Var will no longer have HasProperty, HasMethod, GetProperty, GetAllPropertyNames, SetProperty, RemoveProperty, Call, or Construct. (Use PostMessage and HandleMessage on pp::Instance instead).
    • pp::Instance will no longer have GetInstanceObject, GetWindowObject, GetOwnerElementObject, or ExecuteScript. Use PostMessage and HandleMessage instead.
  • Event handlers are used in place of nacl_element.onload= in JavaScript to handle various situations while module loads. The SDK Examples in this release and the Tutorial cover these new features.
  • The interface version of PPB_Core has been changed and is not backwards-compatible.
  • The 'nacl' attribute of the HTML embed tag has been changed to 'src' and is not backwards-compatible.

Documentation

The Pepper C++ API Reference documentation is now available on code.google.com. This documentation is preliminary; portions of some classes, such as instance.h, have not been documented.

SDK 0.3 (17 May 2011)


  • Native Client modules compiled with version 0.3 of the SDK run only in Chrome 12. Modules compiled with earlier versions of the SDK will not run in Chrome 12.

    Native Client is an experimental feature in Chrome that will be turned on by default once its application binary interface (ABI) stabilizes. Until the ABI stabilizes, there will be occasional changes to the Native Client interfaces. Consequently it is important to match the version of the SDK used to compile a Native Client module with the version of Chrome used to run that module. We apologize for this inconvenience – the need to match versions of the Native Client SDK with versions of Chrome is strictly temporary.

SDK 0.2 (19 April 2011)

General notes

  • Native Client modules compiled with version 0.2 of the SDK run only in Chrome 11. If you are targeting Chrome 10, you must use version 0.1 of the SDK. The Download page provides links to both versions of the SDK.
  • PPB_Core.CallOnMainThread() is now supported.
  • On Linux, it is no longer necessary to use the --no-sandbox option when running Chrome 11.

Library changes

  • In version 0.2 of the SDK, the libraries listed below have been renamed:
    Old library name in SDK 0.1 New library name in SDK 0.2
    google_nacl_imc imc
    google_nacl_imc_c imc
    google_nacl_platform platform

    If you want to use version 0.2 of the SDK to compile a Native Client module that you previously compiled with version 0.1 of the SDK, you must change the old library names to the new library names in your module's Makefile. One location where you will likely need to change library names is the LDFLAGS variable definition in your Makefile.

  • The libraries listed below have been removed in version 0.2 of the SDK (these libraries were needed to use NPAPI and a previous version of the Pepper API, which Native Client no longer supports):
    • google_nacl_npruntime
    • google_nacl_gpu
    • google_nacl_pgl

SDK 0.1 "Arctic Sea" (17 February 2011)

General notes

  • This release of the Native Client SDK includes support for Pepper (PPAPI) interfaces and improved security. For more information about Pepper see the Pepper reference documentation. For additional highlights of the Arctic Sea release see Native Client: Getting Ready for Takeoff.
  • Arctic Sea is a developer release. Some features of Native Client and the Native Client SDK may not work as expected, and the code in both is likely to change.
  • To run web applications that use Native Client, you must use Google Chrome version 10.x or greater with Native Client enabled. See running Native Client web applications for additional information.
  • Native Client no longer supports NPAPI. Native Client applications that were previously made using NPAPI will not run in Google Chrome as of version 10.
  • The documentation published with this developer release reflects the early nature of the release. Forthcoming production releases will include more comprehensive and detailed documentation, including a Developer Guide.
  • Native Client and the Native Client SDK are open-source projects. If you'd like to contribute to either project, see nativeclient.googlecode.com and nativeclient-sdk.googlecode.com.

Known issues

  • Windows:
    • Moving the SDK from the directory in which it's installed may break some links that are needed for compiling.
    • Native Client does not currently run on Windows XP 64-bit systems.
    • On Windows XP 32-bit systems, the examples in the SDK sometimes do not work when they are open simultaneously in different tabs.
    • nacl-sel_ldr and nacl-sel_ldr64 do not work on Windows. Compiled .nexe modules run in Chrome, but they cannot run stand-alone (e.g., as part of a unit testing framework).
  • Mac:
    • The Native Client SDK requires Mac OS X 10.6 Snow Leopard or greater.
  • Linux:
    • Chrome (and by extension Native Client) is supported on 32- and 64-bit Ubuntu 8.04 and later, and 32-bit Debian 5. OpenSuSE 11.3 is known not to work. Other Linux distributions such as Fedora may work but are not supported.
    • You must run Chrome with the --no-sandbox flag in order for Native Client to work. (The Chrome Dev channel already has a fix for this issue.)
    • The SDK has a number of dependencies that you may need to resolve by manually installing libraries (e.g., libcrypto.so.0.9.8, zlib-32bit).
  • For the Conway's Life application on the Examples page, you may need to press Ctrl-R to refresh the screen in order for the graphical simulation to be displayed.
  • For up-to-date information and fixes for existing issues, or to report a new issue, check the Native Client Issue Tracker.

Limitations

  • In this release of the Native Client SDK, all available Pepper functions must be invoked from the main Pepper/JavaScript thread of execution.
  • Native Client does not yet support 3D graphics, file I/O, or peer-to-peer networking.
  • Native Client does not yet support devices such as cameras and microphones. Device support needs to be finalized in HTML5 before it can be added to Native Client.
  • The Native Client SDK does not yet support interactive debuggers. We are working to add support for interactive debuggers as soon as possible.

Whitelist of Pepper (PPAPI) functions

  • The functions below are known to work (they are either called from SDK code or tested as part of the Native Client project). Other functions in the Pepper API may or may not work as expected; a few are still being implemented as of this release. We expect the entire Pepper API to be completed and tested shortly. Note that PPB_Var and PPB_Var_Deprecated will be replaced by PostMessage().
    • PPB_GetInterface()
    • PPB_Core.AddRefResource()
    • PPB_Core.ReleaseResource()
    • PPB_Core.MemAlloc()
    • PPB_Core.MemFree()
    • PPB_Core.GetTime()
    • PPB_Core.GetTimeTicks()
    • PPB_Core.IsMainThread()
    • PPB_Graphics2D.Create()
    • PPB_Graphics2D.PaintImageData()
    • PPB_Graphics2D.ReplaceContents()
    • PPB_Graphics2D.Flush()
    • PPB_ImageData.Create()
    • PPB_ImageData.Describe()
    • PPB_ImageData.Map()
    • PPB_Instance.GetWindowObject()
    • PPB_Instance.BindGraphics()
    • PPB_URLLoader.Create()
    • PPB_URLLoader.IsURLLoader()
    • PPB_URLLoader.Open()
    • PPB_URLLoader.GetResponseInfo()
    • PPB_URLLoader.ReadResponseBOdy()
    • PPB_URLLoader.FinishStreamingToFile()
    • PPB_URLRequestInfo.Create()
    • PPB_URLRequestInfo.IsURLRequestInfo()
    • PPB_URLRequestInfo.SetProperty()
    • PPB_URLResponseInfo.IsURLResponseInfo()
    • PPB_URLResponseInfo.GetProperty()
    • PPB_URLResponseInfo.GetBodyAsFileRef()
    • PPB_AudioConfig.CreateStereo16Bit()
    • PPB_AudioConfig.RecommendedSampleFrameCount()
    • PPB_Audio.Create()
    • PPB_Audio.StartPlayback()
    • PPB_Audio.StopPlayback()
    • PPB_Var_Deprecated.Release()
    • PPB_Var_Deprecated.VarFromUtf8()
    • PPB_Var_Deprecated.VarToUtf8()
    • PPB_Var_Deprecated.HasProperty()
    • PPB_Var_Deprecated.HasMethod()
    • PPB_Var_Deprecated.GetProperty()
    • PPB_Var_Deprecated.SetProperty()
    • PPB_Var_Deprecated.Call()
    • PPP_InitializeModule()
    • PPP_ShutdownModule()
    • PPP_GetInterface()
    • PPP_Instance.DidCreate()
    • PPP_Instance.DidDestroy()
    • PPP_Instance.DidChangeView()
    • PPP_Instance.GetInstanceObject()

Authentication required

You need to be signed in with Google+ to do that.

Signing you in...

Google Developers needs your permission to do that.