[NaCl SDK] Remove references to naclports bundle

native_client_sdk/src/doc/reference/pnacl-c-cpp-language-support.rst

 ============================
 PNaCl C/C++ Language Support
 ============================
 
 .. contents::
    :local:
    :backlinks: none
    :depth: 3
 
 Source language support
@@ skipping 165 matching lines @@
 ======================
 
 PNaCl currently supports C++ exception handling through ``setjmp()`` and
 ``longjmp()``, which can be enabled with the ``--pnacl-exceptions=sjlj`` linker
 flag (set with ``LDFLAGS`` when using Make). Exceptions are disabled by default
 so that faster and smaller code is generated, and ``throw`` statements are
 replaced with calls to ``abort()``. The usual ``-fno-exceptions`` flag is also
 supported, though the default is ``-fexceptions``. PNaCl will support full
 zero-cost exception handling in the future.
 
-.. note:: When using naclports_ or other prebuilt static libraries, you don't
+.. note:: When using webports_ or other prebuilt static libraries, you don't
           need to recompile because the exception handling support is
           implemented at link time (when all the static libraries are put
           together with your application).
 
-.. _naclports: https://code.google.com/p/naclports
+.. _webports: https://chromium.googlesource.com/webports
 
 NaCl supports full zero-cost C++ exception handling.
 
 Inline Assembly
 ===============
 
 Inline assembly isn't supported by PNaCl because it isn't portable. The
 one current exception is the common compiler barrier idiom
 ``asm("":::"memory")``, which gets transformed to a sequentially
 consistent memory barrier (equivalent to ``__sync_synchronize()``). In
@@ skipping 274 matching lines @@
   A similar feature is **thread suspension**: The ability to
   asynchronously suspend and resume a thread and inspect or modify its
   execution state (such as register state).
 
   Neither PNaCl nor NaCl currently support asynchronous interruption
   or suspension of threads.
 
 If PNaCl were to support either of these, the interaction of
 ``volatile`` and atomics with same-thread signal handling would need
 to be carefully detailed.