| .. _sdk-release-notes: |
| |
| ############# |
| Release Notes |
| ############# |
| |
| The dates in the following release notes denote when Chrome and the NaCl SDK |
| reached canary status. The stable release is typically 6 weeks later. |
| |
| |
| Chrome/Pepper 45 (10 July 2015) |
| ================================ |
| |
| Pepper |
| ------ |
| |
| * UDP Socket Multicast API in stable (PPB_UDP_SOCKET 1.2). |
| |
| Chrome/Pepper 43 (03 April 2015) |
| ================================ |
| |
| PNaCl |
| ----- |
| |
| * The C11/C++11 ``acquire``, ``release``, and ``acq_rel`` memory orders are now |
| generated by default. The in-browser Chrome 42 translator supports them, the |
| SDK can therefore generate them. |
| * Fix a `code generation bug on ARM`_ when dealing with 16-bit load/store and |
| ``bswap`` which led to a NaCl validation failure. |
| * PNaCl is now based on LLVM 3.6. If you are using GDB to debug PNaCl |
| :ref:`BC files with debug metadata in the browser<debugging_pnacl_pexes>`, |
| remember that debug info from SDK version ``X`` is only compatible with the |
| PNaCl translator in chrome version ``X``. The bitcode debug metadata format |
| changed from LLVM 3.5 to 3.6. If you need to debug an app built with SDK |
| version ``X`` running in Chrome version ``Y`` (with ``X != Y``), it is still |
| possible to do so. Simply translate the pexe to a nexe using the |
| :ref:`offline pnacl-translate tool from SDK version X |
| <debugging_pexes_via_nexes>` instead of using the translator in the |
| browser (version ``Y``). |
| * PNaCl's support for use of libstdc++ 4.6 as the C++ standard library is |
| deprecated and will be removed in the next release. PNaCl has used libc++ |
| (which is much more up-to-date, currently based on LLVM 3.6) as the default |
| since Pepper 33. |
| * PNaCl's experimental `Subzero translator`_ is available for x86-32 NaCl in |
| Chrome version 43, behind a flag. To give it a try, run Chrome with the |
| ``--enable-pnacl-subzero`` commandline flag, and use the ``optlevel 0`` |
| :ref:`NaCl manifest option<pnacl_nmf_optlevels>`. Application startup time |
| should be several times faster than the previous LLVM-based ``optlevel 0`` |
| mode, with similar code quality. Note that x86-32 NaCl requires a 32-bit |
| Chrome. On Windows, it also requires a 32-bit Windows OS, but 64-bit Linux |
| OSes can run x86-32 NaCl. If you try it out, please send us feedback |
| on `native-client-dev`_. We are working on improvements and adding |
| new targets. |
| |
| .. _`code generation bug on ARM`: https://code.google.com/p/chromium/issues/detail?id=460432 |
| .. _`Subzero translator`: https://chromium.googlesource.com/native_client/pnacl-subzero/+/master/README.rst |
| .. _`native-client-dev`: https://groups.google.com/forum/#!forum/native-client-dev |
| |
| Pepper |
| ------ |
| |
| * UDP Socket Multicast API in development preview (PPB_UDP_SOCKET 1.2). |
| * Hardware Video Encoder API in development preview (PPB_VIDEO_ENCODER 0.1). |
| |
| Chrome/Pepper 42 (20 February 2015) |
| =================================== |
| |
| SDK |
| --- |
| |
| * The SDK now contains experimental versions of ``i686-nacl-clang``, |
| ``x86_64-nacl-clang``, and ``arm-nacl-clang`` as well as the ``clang++`` |
| equivalents. These toolchains are based on the same LLVM version as PNaCl, but |
| can be used to generate NaCl ``.nexe`` files instead of translating a |
| ``.pexe`` locally or using the GCC toolchain. |
| |
| NaCl |
| ---- |
| |
| * The x86 NaCl validators accept instructions from the FMA3 extensions, as well |
| as AVX2 instructions (except ``VGATHER``). |
| |
| PNaCl |
| ----- |
| |
| * PNaCl supports C11/C++11 memory orders ``acquire``, ``release``, and |
| ``acq_rel``. It used to upgrade all accesses to ``seq_cst``. It still upgrades |
| ``consume`` to ``acquire`` (no compiler currently implements ``consume``), and |
| ``relaxed`` to ``seq_cst`` (to conservatively avoid platform differences due |
| to out-of-thin-air problems). This is currently disabled by default in the SDK |
| so that the in-browser translator installed on users' machines has time to |
| gain this support. Developers can turn it on by passing the |
| ``-pnacl-memory-order-seq-cst-only=false`` flag to ``opt``. |
| * PNaCl handles nested struct type expansion, which allows it to better support |
| non-C languages such as Rust. |
| * PNaCl breaks up many integer operations over 64-bits into individual 64-bit |
| operations. This is often encountered when using large consecutive bitfields. |
| |
| Chrome/Pepper 41 (09 January 2015) |
| ================================== |
| |
| NaCl |
| ---- |
| |
| * The x86 NaCl validators accept instructions from the AVX1 extensions. |
| |
| PNaCl |
| ----- |
| |
| * PNaCl is now based on LLVM 3.5. |
| |
| Chrome/Pepper 40 (November 07 2014) |
| =================================== |
| |
| * `VideoDecoder |
| </native-client/pepper_stable/cpp/classpp_1_1_video_decoder.html>`_ is now |
| stable, see the SDK example in ``pepper_canary/examples/api/video_decode``. |
| |
| Chrome/Pepper 39 (26 September 2014) |
| ==================================== |
| |
| NaCl |
| ---- |
| |
| * This release contains a fix for CVE-2015-0565: `disable the x86 CLFLUSH |
| instruction due to rowhammer problem |
| <https://code.google.com/p/nativeclient/issues/detail?id=3944>`_. |
| |
| Pepper |
| ------ |
| |
| * Support for ``DEBUG_ONLY:dev://postmessage`` has been removed in favor of |
| :ref:`other more useful debugging approaches <devcycle-debugging>`. |
| * ``postMessageAndAwaitResponse`` is now stable and allows JavaScript to |
| `communicate synchronously |
| </native-client/pepper_stable/cpp/classpp_1_1_message_handler>`_ with PNaCl |
| embeds. |
| |
| Chrome/Pepper 38 (15 August 2014) |
| ================================= |
| |
| PNaCl |
| ----- |
| |
| * Compilation speed improvements due to validation caching of the translator and |
| linker. |
| * Performance improvement of SIMD vector shuffle. |
| |
| Chrome/Pepper 37 (20 June 2014) |
| =============================== |
| |
| PNaCl |
| ----- |
| |
| * 2–10% translation time improvement. |
| * Improved vector load/store and shuffle performance. |
| |
| Pepper |
| ------ |
| |
| * Media Streams Input support. |
| * Compositor API. |
| * Hardware Decode API in development preview. |
| * Sync API in development preview. |
| |
| SDK |
| --- |
| |
| * Demo of a :ref:`full development environment in the browser <io2014>`. |
| |
| Chrome/Pepper 36 (09 May 2014) |
| ============================== |
| |
| PNaCl |
| ----- |
| * Support `LLVM vectors |
| <http://clang.llvm.org/docs/LanguageExtensions.html#vectors-and-extended-vectors>`_ |
| and `GCC vectors |
| <http://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html>`_ for SIMD |
| vectors through :ref:`Portable SIMD Vectors |
| <portable_simd_vectors>`. Note that this is still an early release, |
| and performance is expected to become acceptable for version 37 of |
| Chrome. More SIMD instructions will be added in later releases. |
| |
| Chrome/Pepper 35 (31 Mar 2014) |
| ============================== |
| |
| PNaCl |
| ----- |
| * Upgraded LLVM to version 3.4. |
| * Translation now uses dynamic load balancing, making translation time faster. |
| * Unstable pexes (i.e. non-finalized) with debug information can be loaded by |
| Chrome, simplifying debugging with PNaCl. See :ref:`Debugging PNaCl pexes |
| <debugging_pnacl_pexes>` |
| |
| |
| Chrome/Pepper 34 (20 Feb 2014) |
| ============================== |
| |
| Pepper |
| ------ |
| * Filesystems can now be passed from JavaScript to NaCl. The resulting |
| ``pp::Var`` will contain a ``pp::Resource`` that can be given to the |
| ``pp::FileSystem`` constructor. |
| * New Audio and Video input APIs have been added as dev interfaces. See |
| `pp::MediaStreamAudioTrack |
| </native-client/pepper_dev/cpp/classpp_1_1_media_stream_audio_track>`_ and |
| `pp::MediaStreamVideoTrack |
| </native-client/pepper_dev/cpp/classpp_1_1_media_stream_video_track>`_ for |
| more details. |
| |
| PNaCl |
| ----- |
| * Parallel translation: at least 1.7x faster, even with older pexes. |
| * Intelligent abbreviations in the bitcode: 20% reduction in binary size using |
| the :ref:`pnacl-compress <pnacl_compress>` tool. |
| |
| Chrome/Pepper 33 (16 Dec 2013) |
| ============================== |
| |
| Portable Native Client |
| ---------------------- |
| |
| * PNaCl's default C++ standard library is now LLVM's own libc++, based on |
| LLVM 3.3. This library now supports optional ``setjmp``/``longjmp`` exception |
| handling (see `announcement |
| <https://groups.google.com/forum/#!topic/native-client-discuss/0spfg6O04FM>`_ |
| for details). |
| |
| SDK |
| --- |
| |
| * The ``nacl_io`` library now includes a FUSE mount. |
| * In the SDK examples, ``common.js`` now loads the Release version of the |
| nexes/pexes that are built (by default). |
| * "``make debug``" and "``make run``" have been fixed on Mac. |
| |
| PNaCl enabled by default in Chrome 31 (12 Nov 2013) |
| =================================================== |
| |
| * Portable Native Client (PNaCl) is enabled by default in Chrome 31. See |
| :doc:`NaCl and PNaCl </nacl-and-pnacl>` for details on the differences between |
| NaCl and PNaCl. |
| * The PNaCl ABI has changed from the preview release in Chrome 30. |
| Pexe modules built with the ``pepper_30`` bundle in the SDK must be recompiled |
| with the ``pepper_31`` bundle or later. |
| As a general rule, we always recommended building applications with the latest |
| stable bundle in the Native Client SDK. |
| The PNaCl ABI will remain stable starting with the release of Chrome 31. |
| * Additional changes in the Chrome/Pepper 31 release: |
| |
| * Updates to the Pepper API, including socket and network support |
| * Improved socket support in the ``nacl_io`` library |
| |
| 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 |
| <http://www.chromium.org/nativeclient/pnacl/introduction-to-portable-native-client>`_ |
| for information on developing for PNaCl. More documentation will be available |
| soon. |
| * Please note that the `PNaCl bitcode ABI |
| <http://www.chromium.org/nativeclient/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 `Chrome apps </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 <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 :ref:`newlib C library <c_libraries>`. You cannot use the ARM toolchain |
| to compile modules that use the glibc library. |
| * The ARM toolchain is in the directory |
| ``pepper_25/toolchain/<host>_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 |
| </native-client/pepper_stable/c/struct_p_p_b___console__1__0>`_ lets your |
| module log messages to the JavaScript console in the Chrome browser. |
| * The `MessageLoop |
| </native-client/pepper_stable/cpp/classpp_1_1_message_loop>`_ 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 :ref:`local file IO <devguide-coding-fileio>` in |
| Chrome (for example, prior to using an html5fs file system, you must `enable |
| local file IO <enabling_file_access>`_). |
| |
| * 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 |
| <http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf>`_ (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 |
| </native-client/pepper_stable/c/group___enums#ga7df48e1c55f6401beea2a1b9c07967e8>`_ |
| 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 :ref:`nacl-gdb debugger <using_gdb>` 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_28``). |
| |
| 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: |
| |
| #. 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. |
| #. 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 |
| :ref:`local server <web_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 </extensions/manifest>`_. By default, |
| applications that use version 2 of the manifest file format apply a strict |
| `content security policy </extensions/contentSecurityPolicy>`_, 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 </extensions/manifestVersion>`_ 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 |
| ----- |
| |
| * `PP_InputEvent_Modifier |
| </native-client/pepper_stable/c/group___enums#ga21b811ac0484a214a8751aa3e1c959d9>`_ |
| has two new enum values (_ISLEFT and _ISRIGHT). |
| * The memory leak in the `WebSocket |
| </native-client/pepper_stable/c/struct_p_p_b___web_socket__1__0>`_ API has |
| been fixed. |
| |
| 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 :ref:`Debugging with nacl-gdb |
| <devcycle-debugging>` 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: |
| |
| #. 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. |
| #. 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:: |
| :class: note |
| |
| **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 |
| <http://dev.chromium.org/developers/how-tos/get-the-code>`_ and then follow |
| the `Mac instructions |
| <http://www.chromium.org/nativeclient/how-tos/debugging-documentation/debugging-a-trusted-plugin/trusted-debugging-on-mac>`_ |
| or `Linux instructions |
| <http://www.chromium.org/nativeclient/how-tos/debugging-documentation/debugging-a-trusted-plugin/debugging-a-trusted-plugin-on-linux>`_. |
| 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 :ref:`Compile flags for |
| different development scenarios <compile_flags>`. |
| * 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 |
| ----- |
| |
| * The ``CompletionCallbackFactory`` class template now takes a thread traits |
| class as its second parameter. For details see the `CompletionCallbackFactory |
| class template reference |
| </native-client/pepper_stable/cpp/classpp_1_1_completion_callback_factory#details>`_. |
| |
| .. TODO: Port release notes for older releases |
