</li>
</ul>
-</div><section id="introduction">
-<h2 id="introduction">Introduction</h2>
+</div><h2 id="introduction">Introduction</h2>
<p>This document describes how to build Native Client modules. It is intended for
developers who have experience writing, compiling, and linking C and C++ code.
If you haven’t read the Native Client <a class="reference internal" href="/native-client/overview.html"><em>Technical Overview</em></a> and <a class="reference internal" href="/native-client/devguide/tutorial/index.html"><em>Tutorial</em></a>, we recommend starting
with those.</p>
-<section id="target-architectures">
-<span id="id1"></span><h3 id="target-architectures"><span id="id1"></span>Target architectures</h3>
+<h3 id="target-architectures"><span id="id1"></span>Target architectures</h3>
<p>Portable Native Client (PNaCl) modules are written in C or C++ and compiled
into an executable file ending in a <strong>.pexe</strong> extension using the PNaCl
toolchain in the Native Client SDK. Chrome can load <strong>pexe</strong> files
embedded in web pages and execute them as part of a web application.</p>
<p>As explained in the Technical Overview, PNaCl modules are
-operating-system-independent <strong>and</strong> processor-independent. The same
-<strong>pexe</strong> will run on Windows, Mac, Linux, and ChromeOS and it will run on
-any processor, e.g., x86-32, x86-64, and ARM.</p>
+operating-system-independent <strong>and</strong> processor-independent. The same <strong>pexe</strong>
+will run on Windows, Mac OS X, Linux, and ChromeOS and it will run on x86-32,
+x86-64, ARM and MIPS processors.</p>
<p>Native Client also supports architecture-specific <strong>nexe</strong> files.
These <strong>nexe</strong> files are <strong>also</strong> operating-system-independent,
but they are <strong>not</strong> processor-independent. To support a wide variety of
for multiple target architectures and how to generate manifest files, see the
Makefiles included with the SDK examples.</p>
<p>This section will mostly cover PNaCl, but also describes how to build
-nexe applications.</p>
-</section><section id="c-libraries">
+<strong>nexe</strong> applications.</p>
<h3 id="c-libraries">C libraries</h3>
<p>The PNaCl SDK has a single choice of C library: <a class="reference external" href="http://sourceware.org/newlib/">newlib</a>.</p>
<p>The Native Client SDK also has a GCC-based toolchain for building
<strong>nexes</strong>. The GCC-based toolchain has support for two C libraries:
<a class="reference external" href="http://sourceware.org/newlib/">newlib</a> and <a class="reference external" href="http://www.gnu.org/software/libc/">glibc</a>. See <a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html"><em>Dynamic Linking & Loading with glibc</em></a> for information about these libraries, including factors to
help you decide which to use.</p>
-</section><section id="c-standard-libraries">
-<span id="building-cpp-libraries"></span><h3 id="c-standard-libraries"><span id="building-cpp-libraries"></span>C++ standard libraries</h3>
+<h3 id="c-standard-libraries"><span id="building-cpp-libraries"></span>C++ standard libraries</h3>
<p>The PNaCl SDK can use either LLVM’s <a class="reference external" href="http://libcxx.llvm.org/">libc++</a>
(the current default) or GCC’s <a class="reference external" href="http://gcc.gnu.org/libstdc++">libstdc++</a> (deprecated). The
<code>-stdlib=[libc++|libstdc++]</code> command line argument can be used to
choose which standard library to use.</p>
<p>The GCC-based Native Client SDK only has support for GCC’s <a class="reference external" href="http://gcc.gnu.org/libstdc++">libstdc++</a>.</p>
-<p>C++11 library support is only complete in libc++ but other non-library
-language features should work regardless of which standard library is
-used. The <code>-std=[c++98|c++11]</code> command line argument can be used to
-indicate which C++ language standard to use (or <code>-std=gnu++11</code> to
-access non-standard extensions).</p>
-</section><section id="sdk-toolchains">
+<p>C++11 library support is only complete in libc++ but other non-library language
+features should work regardless of which standard library is used. The
+<code>-std=gnu++11</code> command line argument can be used to indicate which C++
+language standard to use (<code>-std=c++11</code> often doesn’t work well because newlib
+relies on some GNU extensions).</p>
<h3 id="sdk-toolchains">SDK toolchains</h3>
<p>The Native Client SDK includes multiple toolchains. It has one PNaCl toolchain
and it has multiple GCC-based toolchains that are differentiated by target
toolchains are located in directories named
<code>toolchain/<OS_platform>_<architecture>_<library></code>, where:</p>
<ul class="small-gap">
-<li><em><platform></em> is the platform of your development machine (win, mac, or linux)</li>
-<li><em><architecture></em> is your target architecture (x86 or arm)</li>
-<li><em><library></em> is the C library you are compiling with (newlib or glibc)</li>
+<li><dl class="first docutils">
+<dt><em><platform></em> is the platform of your development machine (<em>win</em>, <em>mac</em>, or</dt>
+<dd><em>linux</em>)</dd>
+</dl>
+</li>
+<li><em><architecture></em> is your target architecture (<em>x86</em> or <em>arm</em>)</li>
+<li><em><library></em> is the C library you are compiling with (<em>newlib</em> or <em>glibc</em>)</li>
</ul>
<p>The compilers, linkers, and other tools are located in the <code>bin/</code>
subdirectory in each toolchain. For example, the tools in the Windows SDK
for PNaCl has a C++ compiler in <code>toolchain/win_pnacl/bin/pnacl-clang++</code>.
-As another example, the GCC-based C++ compiler that targets the x86 and uses the
+As another example, the GCC-based C++ compiler that targets x86 and uses the
newlib library, is located at <code>toolchain/win_x86_newlib/bin/x86_64-nacl-g++</code>.</p>
<aside class="note">
The SDK toolchains descend from the <code>toolchain/</code> directory. The SDK also
testing your application (e.g., the <code>create_nmf.py</code> script, which you can
use to create a manifest file).
</aside>
-</section><section id="sdk-toolchains-versus-your-hosted-toolchain">
<h3 id="sdk-toolchains-versus-your-hosted-toolchain">SDK toolchains versus your hosted toolchain</h3>
<p>To build NaCl modules, you must use one of the Native Client toolchains
included in the SDK. The SDK toolchains use a variety of techniques to
document covers only compiling C and C++ code, using the toolchains
provided in the SDK.
</aside>
-</section></section><section id="the-pnacl-toolchain">
<h2 id="the-pnacl-toolchain">The PNaCl toolchain</h2>
<p>The PNaCl toolchain contains modified versions of the tools in the
LLVM toolchain, as well as linkers and other tools from binutils.
To determine which version of LLVM or binutils the tools are based upon,
run the tool with the <code>--version</code> command line flag. These tools
-are used to compile and link applications into .pexe files. The toolchain
-also contains a tool to translate a .pexe file into a
-architecture-specific .nexe (e.g., for debugging purposes).</p>
+are used to compile and link applications into <strong>.pexe</strong> files. The toolchain
+also contains a tool to translate a <strong>pexe</strong> file into a
+architecture-specific <strong>.nexe</strong> (e.g., for debugging purposes).</p>
<p>Each tool’s name is preceded by the prefix “pnacl-”. Some of the useful
tools include:</p>
<dl class="docutils">
</dl>
<p>For the full list of tools, see the
<code><NACL_SDK_ROOT>/toolchain/<platform>_pnacl/bin</code> directory.</p>
-</section><section id="using-the-pnacl-tools-to-compile-link-debug-and-deploy">
<h2 id="using-the-pnacl-tools-to-compile-link-debug-and-deploy">Using the PNaCl tools to compile, link, debug, and deploy</h2>
<p>To build an application with the PNaCl SDK toolchain, you must compile
your code, link it, test and debug it, and then deploy it. This section goes
over some examples of how to use the tools.</p>
-<section id="compile">
<h3 id="compile">Compile</h3>
<p>To compile a simple application consisting of <code>file1.cc</code> and <code>file2.cc</code> into
<code>hello_world.pexe</code> with a single command, use the <code>pnacl-clang++</code> tool</p>
before actually deploying the application to keep the application’s
download size small.</dd>
<dt><code>-On</code></dt>
-<dd><p class="first">sets the optimization level to n. Use 0 when debugging, and -O2 or -O3
-for profiling and deployment.</p>
-<p class="last">The main difference between -O2 and -O3 is whether the compiler performs
-optimizations that involve a space-speed tradeoff. It could be the case that
-<code>-O3</code> optimizations are not desirable due to increased <strong>pexe</strong>
+<dd><p class="first">sets the optimization level to n. Use <code>-O0</code> when debugging, and <code>-O2</code> or
+<code>-O3</code> for deployment.</p>
+<p class="last">The main difference between <code>-O2</code> and <code>-O3</code> is whether the compiler
+performs optimizations that involve a space-speed tradeoff. It could be the
+case that <code>-O3</code> optimizations are not desirable due to increased <strong>pexe</strong>
download size; you should make your own performance measurements to determine
-which level of optimization is right for you. When looking at code size,
-note that what you generally care about is not the size of the pexe
-produced by pnacl-clang, but the size of the compressed pexe that you upload
-your application to the server or to the Chrome Web Store.
-Optimizations that increase the size of a pexe may not increase the size of
-the compressed pexe that much.</p>
+which level of optimization is right for you. When looking at code size, note
+that what you generally care about is not the size of the <strong>pexe</strong> produced by
+<code>pnacl-clang</code>, but the size of the compressed <strong>pexe</strong> that you upload to
+the server or to the Chrome Web Store. Optimizations that increase the size of
+an uncompressed <strong>pexe</strong> may not increase the size of the compressed <strong>pexe</strong>
+very much. You should also verify how optimization level affects on-device
+translation time, this can be tested locally with <code>pnacl-translate</code>.</p>
</dd>
<dt><code>-I<directory></code></dt>
<dd>adds a directory to the search path for <strong>include</strong> files. The SDK has
Pepper (PPAPI) headers located at <code><NACL_SDK_ROOT>/include</code>, so add
that directory when compiling to be able to include the headers.</dd>
+<dt><code>-mllvm -inline-threshold=n</code></dt>
+<dd>change how much inlining is performed by LLVM (the default is 225, a smaller
+value will result in less inlining being performed). The right number to
+choose is application-specific, you’ll therefore want to experiment with the
+value that you pass in: you’ll be trading off potential performance with
+<strong>pexe</strong> size and on-device translation speed.</dd>
</dl>
-</section><section id="create-a-static-library">
<h3 id="create-a-static-library">Create a static library</h3>
<p>The <code>pnacl-ar</code> and <code>pnacl-ranlib</code> tools allow you to create a
<strong>static</strong> library from a set of bitcode files, which can later be linked
<NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-ranlib libfoo.a
</pre>
-</section><section id="link-the-application">
<h3 id="link-the-application">Link the application</h3>
<p>The <code>pnacl-clang++</code> tool is used to compile applications, but it can
also be used link together compiled bitcode and libraries into a
full application.</p>
<pre>
<NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-clang++ -o hello_world.pexe ^
- hello_world.o -L<NACL_SDK_ROOT>/lib/pnacl/Debug -lfoo -lppapi_cpp -lppapi
+ hello_world.o -L<NACL_SDK_ROOT>/lib/pnacl/Debug ^
+ -lfoo -lppapi_cpp -lppapi
</pre>
<p>This links the hello world bitcode with the <code>foo</code> library in the example
as well as the <em>Debug</em> version of the Pepper libraries which are located
<em>Release</em> version of the Pepper libraries, change the
<code>-L<NACL_SDK_ROOT>/lib/pnacl/Debug</code> to
<code>-L<NACL_SDK_ROOT>/lib/pnacl/Release</code>.</p>
-</section><section id="finalizing-the-pexe-for-deployment">
+<p>In a release build you’ll want to pass <code>-O2</code> to the compiler <em>as well as to
+the linker</em> to enable link-time optimizations. This reduces the size and
+increases the performance of the final <strong>pexe</strong>, and leads to faster downloads
+and on-device translation.</p>
+<pre>
+<NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-clang++ -o hello_world.pexe ^
+ hello_world.o -L<NACL_SDK_ROOT>/lib/pnacl/Release ^
+ -lfoo -lppapi_cpp -lppapi -O2
+</pre>
+<p>By default the link step will turn all C++ exceptions into calls to <code>abort()</code>
+to reduce the size of the final <strong>pexe</strong> as well as making it translate and run
+faster. If you want to use C++ exceptions you should use the
+<code>--pnacl-exceptions=sjlj</code> linker flag as explained in the <a class="reference internal" href="/native-client/reference/pnacl-c-cpp-language-support.html#exception-handling"><em>exception
+handling</em></a> section of the C++ language support reference.</p>
<h3 id="finalizing-the-pexe-for-deployment">Finalizing the <strong>pexe</strong> for deployment</h3>
-<p>Typically you would run the application to test it and debug it if needed
-before deploying. See the <a class="reference internal" href="/native-client/devguide/devcycle/running.html"><em>running</em></a> documentation for how
-to run a PNaCl application, and see the <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>debugging</em></a>
-documentation for debugging techniques and workflow. After testing a PNaCl
-application, you must <strong>“finalize”</strong> it. The <code>pnacl-finalize</code>
-tool handles this.</p>
+<p>Typically you would run the application to test it and debug it if needed before
+deploying. See the <a class="reference internal" href="/native-client/devguide/devcycle/running.html"><em>running</em></a> documentation for how to run a PNaCl
+application, and see the <a class="reference internal" href="/native-client/devguide/devcycle/debugging.html"><em>debugging</em></a> documentation for
+debugging techniques and workflow. After testing a PNaCl application, you must
+<strong>finalize</strong> it. The <code>pnacl-finalize</code> tool handles this.</p>
<pre>
<NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-finalize ^
hello_world.pexe -o hello_world.final.pexe
</pre>
<p>Prior to finalization, the application <strong>pexe</strong> is stored in a binary
format that is subject to change. After finalization, the application
-pexe is <strong>rewritten</strong> into a different binary format that is <strong>stable</strong>
+<strong>pexe</strong> is <strong>rewritten</strong> into a different binary format that is <strong>stable</strong>
and will be supported by future versions of PNaCl. The finalization step
also helps minimize the size of your application for distribution by
stripping out debug information and other metadata.</p>
refer to the final version of the application before deployment.
The <code>create_nmf.py</code> tool helps generate an <code>.nmf</code> file, but <code>.nmf</code>
files can also be written by hand.</p>
-</section><section id="compressing-the-pexe-for-deployment">
-<span id="pnacl-compress"></span><h3 id="compressing-the-pexe-for-deployment"><span id="pnacl-compress"></span>Compressing the <strong>pexe</strong> for deployment</h3>
-<p>Size compression is an optional step for deployment, and reduces the
-size of the pexe file that must be transmitted over the wire. The tool
-<code>pnacl-compress</code> applies compression strategies that are already built
-into the <strong>stable</strong> binary format of a pexe application. As such,
-compressed pexe files do not need any extra time to be decompressed on
-the client’s side. All costs are upfront when you call <code>pnacl-compress</code>.</p>
-<p>Currently, this tool will compress pexe files by about 25%. However,
+<h3 id="compressing-the-pexe-for-deployment"><span id="pnacl-compress"></span>Compressing the <strong>pexe</strong> for deployment</h3>
+<p>Size compression is an optional step for deployment, and reduces the size of the
+<strong>pexe</strong> file that must be transmitted over the wire, resulting in faster
+download speed. The tool <code>pnacl-compress</code> applies compression strategies that
+are already built into the <strong>stable</strong> binary format of a <strong>pexe</strong>
+application. As such, compressed <strong>pexe</strong> files do not need any extra time to be
+decompressed on the client’s side. All costs are upfront when you call
+<code>pnacl-compress</code>.</p>
+<p>Currently, this tool will compress <strong>pexe</strong> files by about 25%. However,
it is somewhat slow (can take from seconds to minutes on large
appications). Hence, this step is optional.</p>
<pre>
<NACL_SDK_ROOT>/toolchain/win_pnacl/bin/pnacl-compress ^
hello_world.final.pexe
</pre>
-<p>Tool <code>pnacl-compress</code> must be called after a pexe file has been finalized
-for deployment (via <code>pnacl-finalize</code>). Alternatively, you can apply this
-step as part of the finalizing step by adding the <code>--compress</code> flag
-to the pnacl-finalize command line.</p>
-<p>Note that this compression step doesn’t replace gzip. This compression
-step is in addition to gzipping a file for deployment. One should note
-that while the gzipped version of a compressed pexe file is still
-smaller than the corresponding uncompressed pexe file, the gains is
-somewhat smaller after being gzipped. Expected reduction in size
-(after being gzipped) is more like 7.5% to 10%.</p>
-</section></section><section id="the-gnu-based-toolchains">
+<p><code>pnacl-compress</code> must be called after a <strong>pexe</strong> file has been finalized for
+deployment (via <code>pnacl-finalize</code>). Alternatively, you can apply this step as
+part of the finalizing step by adding the <code>--compress</code> flag to the
+<code>pnacl-finalize</code> command line.</p>
+<p>This compression step doesn’t replace the gzip compression performed web servers
+configured for HTTP compression: both compressions are complementary. You’ll
+want to configure your web server to gzip <strong>pexe</strong> files: the gzipped version of
+a compressed <strong>pexe</strong> file is smaller than the corresponding uncompressed
+<strong>pexe</strong> file by 7.5% to 10%.</p>
<h2 id="the-gnu-based-toolchains">The GNU-based toolchains</h2>
<p>Besides the PNaCl toolchain, the Native Client SDK also includes modified
versions of the tools in the standard GNU toolchain, including the GCC
tool—one to build Native Client modules for the x86-32
target architecture, and one to build modules for the x86-64 target
architecture. “i686-nacl-” is the prefix for tools used to build
-32-bit .nexes, and “x86_64-nacl-” is the prefix for tools used to
-build 64-bit .nexes</p>
+32-bit <strong>.nexes</strong>, and “x86_64-nacl-” is the prefix for tools used to
+build 64-bit <strong>.nexes</strong>.</p>
<p>These prefixes conform to gcc naming standards and make it easy to use tools
like autoconf. As an example, you can use <code>i686-nacl-gcc</code> to compile 32-bit
-.nexes, and <code>x86_64-nacl-gcc</code> to compile 64-bit .nexes. Note that you can
-typically override a tool’s default target architecture with command line
+<strong>.nexes</strong>, and <code>x86_64-nacl-gcc</code> to compile 64-bit <strong>.nexes</strong>. Note that you
+can typically override a tool’s default target architecture with command line
flags, e.g., you can specify <code>x86_64-nacl-gcc -m32</code> to compile a 32-bit
-.nexe.</p>
+<strong>.nexe</strong>.</p>
<p>The GNU-based SDK toolchains include the following tools:</p>
<ul class="small-gap">
<li><prefix>addr2line</li>
<li><prefix>strings</li>
<li><prefix>strip</li>
</ul>
-<section id="compiling">
<h3 id="compiling">Compiling</h3>
<p>Compiling files with the GNU-based toolchain is similar to compiling
files with the PNaCl-based toolchain, except that the output is
architecture specific.</p>
<p>For example, assuming you’re developing on a Windows machine, targeting the x86
-architecture, and using the newlib library, you can compile a 32-bit .nexe for
-the hello_world example with the following command:</p>
+architecture, and using the newlib library, you can compile a 32-bit <strong>.nexe</strong>
+for the hello_world example with the following command:</p>
<pre>
<NACL_SDK_ROOT>/toolchain/win_x86_newlib/bin/i686-nacl-gcc hello_world.c ^
-I<NACL_SDK_ROOT>/include -L<NACL_SDK_ROOT>/lib/newlib/Release ^
-o hello_world_x86_32.nexe -m32 -g -O2 -lppapi
</pre>
-<p>To compile a 64-bit .nexe, you can run the same command but use -m64 instead of
--m32. Alternatively, you could also use the version of the compiler that
+<p>To compile a 64-bit <strong>.nexe</strong>, you can run the same command but use -m64 instead
+of -m32. Alternatively, you could also use the version of the compiler that
targets the x86-64 architecture, i.e., <code>x86_64-nacl-gcc</code>.</p>
<p>You should name executable modules with a <strong>.nexe</strong> filename extension,
regardless of what platform you’re using.</p>
-</section><section id="creating-libraries-and-linking">
<h3 id="creating-libraries-and-linking">Creating libraries and Linking</h3>
<p>Creating libraries and linking with the GNU-based toolchain is similar
to doing the same with the PNaCl toolchain. The relevant tools
Linking can be done with <code><prefix>g++</code>. See the
<a class="reference internal" href="/native-client/devguide/devcycle/dynamic-loading.html"><em>Dynamic Linking & Loading with glibc</em></a>
section on how to create <strong>shared</strong> libraries.</p>
-</section><section id="finalizing-a-nexe-for-deployment">
<h3 id="finalizing-a-nexe-for-deployment">Finalizing a <strong>nexe</strong> for deployment</h3>
<p>Unlike the PNaCl toolchain, no separate finalization step is required
-for <strong>nexe</strong> files. The nexe files are always in a <strong>stable</strong> format.
-However, the nexe file may contain debug information and symbol information
-which may make the nexe file larger than needed for distribution.
+for <strong>nexe</strong> files. The <strong>nexe</strong> files are always in a <strong>stable</strong> format.
+However, the <strong>nexe</strong> file may contain debug information and symbol information
+which may make the <strong>nexe</strong> file larger than needed for distribution.
To minimize the size of the distributed file, you can run the
<code><prefix>strip</code> tool to strip out debug information.</p>
-</section></section><section id="using-make">
<h2 id="using-make">Using make</h2>
<p>This document doesn’t cover how to use <code>make</code>, but if you want to use
<code>make</code> to build your Native Client module, you can base your Makefile on the
<ul class="small-gap">
<li><p class="first">If <code>TOOLCHAIN=pnacl</code> creates a subdirectory called <code>pnacl</code>;</p>
<ul class="small-gap">
-<li>builds a .pexe (architecture-independent Native Client executable) using
+<li>builds a <strong>.pexe</strong> (architecture-independent Native Client executable) using
the newlib library</li>
<li>generates a Native Client manifest (.nmf) file for the pnacl version of the
example</li>
</li>
<li><p class="first">If <code>TOOLCHAIN=newlib</code> creates a subdirectory called <code>newlib</code>;</p>
<ul class="small-gap">
-<li>builds .nexes for the x86-32, x86-64, and ARM architectures using the
+<li>builds <strong>.nexes</strong> for the x86-32, x86-64, and ARM architectures using the
newlib library</li>
<li>generates a Native Client manifest (.nmf) file for the newlib version of
the example</li>
</li>
<li><p class="first">If <code>TOOLCHAIN=glibc</code> creates a subdirectory called <code>glibc</code>;</p>
<ul class="small-gap">
-<li>builds .nexes for the x86-32 and x86-64 architectures using the glibc
+<li>builds <strong>.nexes</strong> for the x86-32 and x86-64 architectures using the glibc
library</li>
<li>generates a Native Client manifest (.nmf) file for the glibc version of the
example</li>
to customize the commands that are executed for your project and the options
for each command.</p>
<p>For details on how to use make, see the <a class="reference external" href="http://www.gnu.org/software/make/manual/make.html">GNU ‘make’ Manual</a>.</p>
-</section><section id="libraries-and-header-files-provided-with-the-sdk">
<h2 id="libraries-and-header-files-provided-with-the-sdk">Libraries and header files provided with the SDK</h2>
<p>The Native Client SDK includes modified versions of standard toolchain-support
libraries, such as libpthread and libc, plus the relevant header files.
</ul>
</aside>
-</section><section id="troubleshooting">
<h2 id="troubleshooting">Troubleshooting</h2>
<p>Some common problems, and how to fix them:</p>
-<section id="undefined-reference-error">
<h3 id="undefined-reference-error">“Undefined reference” error</h3>
<p>An “undefined reference” error may indicate incorrect link order and/or
missing libraries. For example, if you leave out <code>-lppapi</code> when
code use POSIX-like file system calls, and implements the calls using
various technologies (e.g., HTML5 file system, read-only filesystems that
use URL loaders, or an in-memory filesystem).</p>
-</section><section id="can-t-find-libraries-containing-necessary-symbols">
<h3 id="can-t-find-libraries-containing-necessary-symbols">Can’t find libraries containing necessary symbols</h3>
<p>Here is one way to find the appropriate library for a given symbol:</p>
<pre>
<NACL_SDK_ROOT>/toolchain/<platform>_pnacl/bin/pnacl-nm -o \
toolchain/<platform>_pnacl/usr/lib/*.a | grep <MySymbolName>
</pre>
-</section><section id="pnacl-abi-verification-errors">
<h3 id="pnacl-abi-verification-errors">PNaCl ABI Verification errors</h3>
<p>PNaCl has restrictions on what is supported in bitcode. There is a bitcode
ABI verifier which checks that the application conforms to the ABI restrictions,
that are <a class="reference internal" href="/native-client/nacl-and-pnacl.html#when-to-use-nacl"><em>not supported by PNaCl</em></a>.
If the problem you face is not listed as restricted,
<a class="reference internal" href="/native-client/help.html#help"><em>let us know</em></a>!</p>
-</section></section></section>
+</section>
{{/partials.standard_nacl_article}}
projects / platform / framework / web / crosswalk.git / blobdiff