[NaCl SDK] Cleanup references to old newlib toolchain

native_client_sdk/doc_generated/devguide/devcycle/dynamic-loading.html

 {{+bindTo:partials.standard_nacl_article}}
 
 <section id="dynamic-linking-and-loading-with-glibc">
 <h1 id="dynamic-linking-and-loading-with-glibc">Dynamic Linking and Loading with glibc</h1>
 <div class="contents local" id="contents" style="display: none">
 <ul class="small-gap">
 <li><a class="reference internal" href="#c-standard-libraries-glibc-and-newlib" id="id1">C standard libraries: glibc and newlib</a></li>
 <li><a class="reference internal" href="#sdk-toolchains" id="id2">SDK toolchains</a></li>
 <li><p class="first"><a class="reference internal" href="#specifying-and-delivering-shared-libraries" id="id3">Specifying and delivering shared libraries</a></p>
 <ul class="small-gap">
@@ skipping 122 matching lines @@
 <colgroup>
 </colgroup>
 <thead valign="bottom">
 <tr class="row-odd"><th class="head">Target architecture</th>
 <th class="head">C library</th>
 <th class="head">Toolchain directory</th>
 </tr>
 </thead>
 <tbody valign="top">
 <tr class="row-even"><td>x86</td>
-<td>newlib</td>
-<td>toolchain/&lt;platform&gt;_x86_newlib</td>
-</tr>
-<tr class="row-odd"><td>x86</td>
 <td>glibc</td>
 <td>toolchain/&lt;platform&gt;_x86_glibc</td>
 </tr>
-<tr class="row-even"><td>ARM</td>
-<td>newlib</td>
-<td>toolchain/&lt;platform&gt;_arm_newlib</td>
+<tr class="row-odd"><td>ARM</td>
+<td>glibc</td>
+<td>toolchain/&lt;platform&gt;_arm_glibc</td>
 </tr>
-<tr class="row-odd"><td>PNaCl</td>
+<tr class="row-even"><td>x86</td>
 <td>newlib</td>
 <td>toolchain/&lt;platform&gt;_pnacl</td>
 </tr>
+<tr class="row-odd"><td>ARM</td>
+<td>newlib</td>
+<td>toolchain/&lt;platform&gt;_pnacl</td>
+</tr>
+<tr class="row-even"><td>PNaCl</td>
+<td>newlib</td>
+<td>toolchain/&lt;platform&gt;_pnacl</td>
+</tr>
 </tbody>
 </table>
 <p>In the directories listed above, &lt;platform&gt; is the platform of your development
 machine (i.e., win, mac, or linux). For example, in the Windows SDK, the x86
 toolchain that uses glibc is in <code>toolchain/win_x86_glibc</code>.</p>
 <aside class="note">
-<strong>Note:</strong> The ARM and PNaCl toolchains are currently restricted to newlib.
+<strong>Note:</strong> The PNaCl toolchain is currently restricted to newlib.
 </aside>
 <p>To use the glibc library and dynamic linking in your application, you <strong>must</strong>
-use a glibc toolchain. (Currently the only glibc toolchain is
-<code>&lt;platform&gt;_x86_glibc</code>.) Note that you must build all code in your application
+use a glibc toolchain.  Note that you must build all code in your application
 with one toolchain. Code from multiple toolchains cannot be mixed.</p>
 <h2 id="specifying-and-delivering-shared-libraries">Specifying and delivering shared libraries</h2>
 <p>One significant difference between newlib and glibc applications is that glibc
 applications must explicitly list and deploy the shared libraries that they
 use.</p>
 <p>In a desktop environment, when the user launches a dynamically linked
 application, the operating system&#8217;s program loader determines the set of
 libraries the application requires by reading explicit inter-module
 dependencies from executable file headers, and loads the required libraries
 into the address space of the application process. Typically the required
@@ skipping 40 matching lines @@
 <dt>dlopen.cc</dt>
 <dd>This file implements the Native Client module, which loads the two shared
 libraries and handles communcation with with JavaScript. The file is compiled
 into a Native Client executable (.nexe).</dd>
 </dl>
 <p>Run <code>make</code> in the dlopen directory to see the commands the Makefile executes
 to build x86 32-bit and 64-bit .nexe and .so files, and to generate a .nmf
 file. These commands are described below.</p>
 <aside class="note">
 <strong>Note:</strong> The Makefiles for most of the examples in the SDK build the
-examples using multiple toolchains (x86 newlib, x86 glibc, ARM, and PNaCl).
-With a few exceptions (listed in the <a class="reference internal" href="/native-client/sdk/release-notes.html#sdk-release-notes"><em>Release Notes</em></a>), running &#8220;make&#8221; in each example&#8217;s directory builds
+examples using multiple toolchains (x86 newlib, x86 glibc, ARM newlib, ARM
+glibc, and PNaCl).  With a few exceptions (listed in the <a class="reference internal" href="/native-client/sdk/release-notes.html#sdk-release-notes"><em>Release Notes</em></a>), running &#8220;make&#8221; in each example&#8217;s directory builds
 multiple versions of the example using the SDK toolchains. The dlopen example
 is one of those exceptions – it is only built with the x86 glibc toolchain,
 as that is currently the only toolchain that supports glibc and thus dynamic
 linking and loading. Take a look at the example Makefiles and the generated
 .nmf files for details on how to build dynamically linked applications.
 </aside>
 <h3 id="generating-a-native-client-manifest-file-for-a-dynamically-linked-application"><span id="dynamic-loading-manifest"></span>Generating a Native Client manifest file for a dynamically linked application</h3>
 <p>The Native Client manifest file specifies the name of the executable to run
 and must also specify any shared libraries that the application directly
 depends on. For indirect dependencies (such as libraries opened via
@@ skipping 172 matching lines @@
 in the .nmf file &#8211; either the files are the wrong type or kind, or an
 expected library is missing.</dd>
 <dt><strong>undefined reference to &#8216;dlopen&#8217; collect2: ld returned 1 exit status</strong></dt>
 <dd>This is a linker ordering problem that usually results from improper ordering
 of command line flags when linking. Reconfigure your command line string to
 list libraries after the -o flag.</dd>
 </dl>
 </section>
 
 {{/partials.standard_nacl_article}}