main/libstdc++-v3/doc/html/manual/abi.html

   1 <?xml version="1.0" encoding="UTF-8" standalone="no"?>
   2 <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>ABI Policy and Guidelines</title><meta name="generator" content="DocBook XSL-NS Stylesheets V1.78.1" /><meta name="keywords" content="C++, ABI, version, dynamic, shared, compatibility" /><meta name="keywords" content="ISO C++, library" /><meta name="keywords" content="ISO C++, runtime, library" /><link rel="home" href="../index.html" title="The GNU C++ Library" /><link rel="up" href="appendix_porting.html" title="Appendix B.  Porting and Maintenance" /><link rel="prev" href="test.html" title="Test" /><link rel="next" href="api.html" title="API Evolution and Deprecation History" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">ABI Policy and Guidelines</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="test.html">Prev</a> </td><th width="60%" align="center">Appendix B.
   3   Porting and Maintenance
   4
   5 </th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="appendix.porting.abi"></a>ABI Policy and Guidelines</h2></div></div></div><p>
   6 </p><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.cxx_interface"></a>The C++ Interface</h3></div></div></div><p>
   7   C++ applications often depend on specific language support
   8   routines, say for throwing exceptions, or catching exceptions, and
   9   perhaps also depend on features in the C++ Standard Library.
  10 </p><p>
  11   The C++ Standard Library has many include files, types defined in
  12   those include files, specific named functions, and other
  13   behavior. The text of these behaviors, as written in source include
  14   files, is called the Application Programing Interface, or API.
  15 </p><p>
  16   Furthermore, C++ source that is compiled into object files is
  17   transformed by the compiler: it arranges objects with specific
  18   alignment and in a particular layout, mangling names according to a
  19   well-defined algorithm, has specific arrangements for the support of
  20   virtual functions, etc. These details are defined as the compiler
  21   Application Binary Interface, or ABI. The GNU C++ compiler uses an
  22   industry-standard C++ ABI starting with version 3. Details can be
  23   found in the <a class="link" href="http://mentorembedded.github.com/cxx-abi/abi.html" target="_top">ABI
  24   specification</a>.
  25 </p><p>
  26  The GNU C++ compiler, g++, has a compiler command line option to
  27   switch between various different C++ ABIs. This explicit version
  28   switch is the flag <code class="code">-fabi-version</code>. In addition, some
  29   g++ command line options may change the ABI as a side-effect of
  30   use. Such flags include <code class="code">-fpack-struct</code> and
  31   <code class="code">-fno-exceptions</code>, but include others: see the complete
  32   list in the GCC manual under the heading <a class="link" href="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code%20Gen%20Options" target="_top">Options
  33   for Code Generation Conventions</a>.
  34 </p><p>
  35   The configure options used when building a specific libstdc++
  36   version may also impact the resulting library ABI. The available
  37   configure options, and their impact on the library ABI, are
  38   documented
  39 <a class="link" href="configure.html" title="Configure">here</a>.
  40 </p><p> Putting all of these ideas together results in the C++ Standard
  41 library ABI, which is the compilation of a given library API by a
  42 given compiler ABI. In a nutshell:
  43 </p><p>
  44   <span class="quote">“<span class="quote">
  45     library API + compiler ABI = library ABI
  46   </span>”</span>
  47 </p><p>
  48  The library ABI is mostly of interest for end-users who have
  49  unresolved symbols and are linking dynamically to the C++ Standard
  50  library, and who thus must be careful to compile their application
  51  with a compiler that is compatible with the available C++ Standard
  52  library binary. In this case, compatible is defined with the equation
  53  above: given an application compiled with a given compiler ABI and
  54  library API, it will work correctly with a Standard C++ Library
  55  created with the same constraints.
  56 </p><p>
  57   To use a specific version of the C++ ABI, one must use a
  58   corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that
  59   implements the C++ ABI in question.
  60 </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.versioning"></a>Versioning</h3></div></div></div><p> The C++ interface has evolved throughout the history of the GNU
  61 C++ toolchain. With each release, various details have been changed so
  62 as to give distinct versions to the C++ interface.
  63 </p><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.goals"></a>Goals</h4></div></div></div><p>Extending existing, stable ABIs. Versioning gives subsequent
  64 releases of library binaries the ability to add new symbols and add
  65 functionality, all the while retaining compatibility with the previous
  66 releases in the series. Thus, program binaries linked with the initial
  67 release of a library binary will still run correctly if the library
  68 binary is replaced by carefully-managed subsequent library
  69 binaries. This is called forward compatibility.
  70 </p><p>
  71 The reverse (backwards compatibility) is not true. It is not possible
  72 to take program binaries linked with the latest version of a library
  73 binary in a release series (with additional symbols added), substitute
  74 in the initial release of the library binary, and remain link
  75 compatible.
  76 </p><p>Allows multiple, incompatible ABIs to coexist at the same time.
  77 </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.history"></a>History</h4></div></div></div><p>
  78  How can this complexity be managed? What does C++ versioning mean?
  79   Because library and compiler changes often make binaries compiled
  80   with one version of the GNU tools incompatible with binaries
  81   compiled with other (either newer or older) versions of the same GNU
  82   tools, specific techniques are used to make managing this complexity
  83   easier.
  84 </p><p>
  85   The following techniques are used:
  86 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Release versioning on the libgcc_s.so binary. </p><p>This is implemented via file names and the ELF
  87     <code class="constant">DT_SONAME</code> mechanism (at least on ELF
  88     systems). It is versioned as follows:
  89     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.x: libgcc_s.so.1</p></li><li class="listitem"><p>GCC 4.x: libgcc_s.so.1</p></li></ul></div><p>For m68k-linux the versions differ as follows: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.4, GCC 4.x: libgcc_s.so.1
  90     when configuring <code class="code">--with-sjlj-exceptions</code>, or
  91     libgcc_s.so.2 </p></li></ul></div><p>For hppa-linux the versions differ as follows: </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.4, GCC 4.[0-1]: either libgcc_s.so.1
  92     when configuring <code class="code">--with-sjlj-exceptions</code>, or
  93     libgcc_s.so.2 </p></li><li class="listitem"><p>GCC 4.[2-7]: either libgcc_s.so.3 when configuring
  94     <code class="code">--with-sjlj-exceptions</code>) or libgcc_s.so.4
  95     </p></li></ul></div></li><li class="listitem"><p>Symbol versioning on the libgcc_s.so binary.</p><p>It is versioned with the following labels and version
  96    definitions, where the version definition is the maximum for a
  97    particular release. Labels are cumulative. If a particular release
  98    is not listed, it has the same version labels as the preceding
  99    release.</p><p>This corresponds to the mapfile: gcc/libgcc-std.ver</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: GCC_3.0</p></li><li class="listitem"><p>GCC 3.3.0: GCC_3.3</p></li><li class="listitem"><p>GCC 3.3.1: GCC_3.3.1</p></li><li class="listitem"><p>GCC 3.3.2: GCC_3.3.2</p></li><li class="listitem"><p>GCC 3.3.4: GCC_3.3.4</p></li><li class="listitem"><p>GCC 3.4.0: GCC_3.4</p></li><li class="listitem"><p>GCC 3.4.2: GCC_3.4.2</p></li><li class="listitem"><p>GCC 3.4.4: GCC_3.4.4</p></li><li class="listitem"><p>GCC 4.0.0: GCC_4.0.0</p></li><li class="listitem"><p>GCC 4.1.0: GCC_4.1.0</p></li><li class="listitem"><p>GCC 4.2.0: GCC_4.2.0</p></li><li class="listitem"><p>GCC 4.3.0: GCC_4.3.0</p></li><li class="listitem"><p>GCC 4.4.0: GCC_4.4.0</p></li><li class="listitem"><p>GCC 4.5.0: GCC_4.5.0</p></li><li class="listitem"><p>GCC 4.6.0: GCC_4.6.0</p></li><li class="listitem"><p>GCC 4.7.0: GCC_4.7.0</p></li><li class="listitem"><p>GCC 4.8.0: GCC_4.8.0</p></li></ul></div></li><li class="listitem"><p>
 100         Release versioning on the libstdc++.so binary, implemented in
 101         the same way as the libgcc_s.so binary above. Listed is the
 102         filename: <code class="constant">DT_SONAME</code> can be deduced from
 103         the filename by removing the last two period-delimited numbers. For
 104         example, filename <code class="filename">libstdc++.so.5.0.4</code>
 105         corresponds to a <code class="constant">DT_SONAME</code> of
 106         <code class="constant">libstdc++.so.5</code>. Binaries with equivalent
 107         <code class="constant">DT_SONAME</code>s are forward-compatibile: in
 108         the table below, releases incompatible with the previous
 109         one are explicitly noted.
 110         If a particular release is not listed, its libstdc++.so binary
 111         has the same filename and <code class="constant">DT_SONAME</code> as the
 112         preceding release.
 113       </p><p>It is versioned as follows:
 114     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: libstdc++.so.3.0.0</p></li><li class="listitem"><p>GCC 3.0.1: libstdc++.so.3.0.1</p></li><li class="listitem"><p>GCC 3.0.2: libstdc++.so.3.0.2</p></li><li class="listitem"><p>GCC 3.0.3: libstdc++.so.3.0.2 (See Note 1)</p></li><li class="listitem"><p>GCC 3.0.4: libstdc++.so.3.0.4</p></li><li class="listitem"><p>GCC 3.1.0: libstdc++.so.4.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li class="listitem"><p>GCC 3.1.1: libstdc++.so.4.0.1</p></li><li class="listitem"><p>GCC 3.2.0: libstdc++.so.5.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li class="listitem"><p>GCC 3.2.1: libstdc++.so.5.0.1</p></li><li class="listitem"><p>GCC 3.2.2: libstdc++.so.5.0.2</p></li><li class="listitem"><p>GCC 3.2.3: libstdc++.so.5.0.3 (See Note 2)</p></li><li class="listitem"><p>GCC 3.3.0: libstdc++.so.5.0.4</p></li><li class="listitem"><p>GCC 3.3.1: libstdc++.so.5.0.5</p></li><li class="listitem"><p>GCC 3.4.0: libstdc++.so.6.0.0 <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li><li class="listitem"><p>GCC 3.4.1: libstdc++.so.6.0.1</p></li><li class="listitem"><p>GCC 3.4.2: libstdc++.so.6.0.2</p></li><li class="listitem"><p>GCC 3.4.3: libstdc++.so.6.0.3</p></li><li class="listitem"><p>GCC 4.0.0: libstdc++.so.6.0.4</p></li><li class="listitem"><p>GCC 4.0.1: libstdc++.so.6.0.5</p></li><li class="listitem"><p>GCC 4.0.2: libstdc++.so.6.0.6</p></li><li class="listitem"><p>GCC 4.0.3: libstdc++.so.6.0.7</p></li><li class="listitem"><p>GCC 4.1.0: libstdc++.so.6.0.7</p></li><li class="listitem"><p>GCC 4.1.1: libstdc++.so.6.0.8</p></li><li class="listitem"><p>GCC 4.2.0: libstdc++.so.6.0.9</p></li><li class="listitem"><p>GCC 4.2.1: libstdc++.so.6.0.9 (See Note 3)</p></li><li class="listitem"><p>GCC 4.2.2: libstdc++.so.6.0.9</p></li><li class="listitem"><p>GCC 4.3.0: libstdc++.so.6.0.10</p></li><li class="listitem"><p>GCC 4.4.0: libstdc++.so.6.0.11</p></li><li class="listitem"><p>GCC 4.4.1: libstdc++.so.6.0.12</p></li><li class="listitem"><p>GCC 4.4.2: libstdc++.so.6.0.13</p></li><li class="listitem"><p>GCC 4.5.0: libstdc++.so.6.0.14</p></li><li class="listitem"><p>GCC 4.6.0: libstdc++.so.6.0.15</p></li><li class="listitem"><p>GCC 4.6.1: libstdc++.so.6.0.16</p></li><li class="listitem"><p>GCC 4.7.0: libstdc++.so.6.0.17</p></li><li class="listitem"><p>GCC 4.8.0: libstdc++.so.6.0.18</p></li><li class="listitem"><p>GCC 4.8.3: libstdc++.so.6.0.19</p></li><li class="listitem"><p>GCC 4.9.0: libstdc++.so.6.0.20</p></li></ul></div><p>
 115       Note 1: Error should be libstdc++.so.3.0.3.
 116     </p><p>
 117       Note 2: Not strictly required.
 118     </p><p>
 119       Note 3: This release (but not previous or subsequent) has one
 120       known incompatibility, see <a class="link" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678" target="_top">33678</a>
 121       in the GCC bug database.
 122     </p></li><li class="listitem"><p>Symbol versioning on the libstdc++.so binary.</p><p>mapfile: libstdc++-v3/config/abi/pre/gnu.ver</p><p>It is versioned with the following labels and version
 123    definitions, where the version definition is the maximum for a
 124    particular release. Note, only symbols which are newly introduced
 125    will use the maximum version definition. Thus, for release series
 126    with the same label, but incremented version definitions, the later
 127    release has both versions. (An example of this would be the
 128    GCC 3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and
 129    GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0
 130    release.) If a particular release is not listed, it has the same
 131    version labels as the preceding release.
 132    </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: (Error, not versioned)</p></li><li class="listitem"><p>GCC 3.0.1: (Error, not versioned)</p></li><li class="listitem"><p>GCC 3.0.2: (Error, not versioned)</p></li><li class="listitem"><p>GCC 3.0.3: (Error, not versioned)</p></li><li class="listitem"><p>GCC 3.0.4: (Error, not versioned)</p></li><li class="listitem"><p>GCC 3.1.0: GLIBCPP_3.1, CXXABI_1</p></li><li class="listitem"><p>GCC 3.1.1: GLIBCPP_3.1, CXXABI_1</p></li><li class="listitem"><p>GCC 3.2.0: GLIBCPP_3.2, CXXABI_1.2</p></li><li class="listitem"><p>GCC 3.2.1: GLIBCPP_3.2.1, CXXABI_1.2</p></li><li class="listitem"><p>GCC 3.2.2: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li class="listitem"><p>GCC 3.2.3: GLIBCPP_3.2.2, CXXABI_1.2</p></li><li class="listitem"><p>GCC 3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1</p></li><li class="listitem"><p>GCC 3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li class="listitem"><p>GCC 3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li class="listitem"><p>GCC 3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1</p></li><li class="listitem"><p>GCC 3.4.0: GLIBCXX_3.4, CXXABI_1.3</p></li><li class="listitem"><p>GCC 3.4.1: GLIBCXX_3.4.1, CXXABI_1.3</p></li><li class="listitem"><p>GCC 3.4.2: GLIBCXX_3.4.2</p></li><li class="listitem"><p>GCC 3.4.3: GLIBCXX_3.4.3</p></li><li class="listitem"><p>GCC 4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1</p></li><li class="listitem"><p>GCC 4.0.1: GLIBCXX_3.4.5</p></li><li class="listitem"><p>GCC 4.0.2: GLIBCXX_3.4.6</p></li><li class="listitem"><p>GCC 4.0.3: GLIBCXX_3.4.7</p></li><li class="listitem"><p>GCC 4.1.1: GLIBCXX_3.4.8</p></li><li class="listitem"><p>GCC 4.2.0: GLIBCXX_3.4.9</p></li><li class="listitem"><p>GCC 4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2</p></li><li class="listitem"><p>GCC 4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3</p></li><li class="listitem"><p>GCC 4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3</p></li><li class="listitem"><p>GCC 4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3</p></li><li class="listitem"><p>GCC 4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4</p></li><li class="listitem"><p>GCC 4.6.0: GLIBCXX_3.4.15, CXXABI_1.3.5</p></li><li class="listitem"><p>GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5</p></li><li class="listitem"><p>GCC 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6</p></li><li class="listitem"><p>GCC 4.8.0: GLIBCXX_3.4.18, CXXABI_1.3.7</p></li><li class="listitem"><p>GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7</p></li><li class="listitem"><p>GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8</p></li></ul></div></li><li class="listitem"><p>Incremental bumping of a compiler pre-defined macro,
 133     __GXX_ABI_VERSION. This macro is defined as the version of the
 134     compiler v3 ABI, with g++ 3.0 being version 100. This macro will
 135     be automatically defined whenever g++ is used (the curious can
 136     test this by invoking g++ with the '-v' flag.)
 137     </p><p>
 138     This macro was defined in the file "lang-specs.h" in the gcc/cp directory.
 139     Later versions defined it in "c-common.c" in the gcc directory, and from
 140     G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the
 141     '-fabi-version' command line option.
 142     </p><p>
 143     It is versioned as follows, where 'n' is given by '-fabi-version=n':
 144     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0: 100</p></li><li class="listitem"><p>GCC 3.1: 100 (Error, should be 101)</p></li><li class="listitem"><p>GCC 3.2: 102</p></li><li class="listitem"><p>GCC 3.3: 102</p></li><li class="listitem"><p>GCC 3.4, GCC 4.x: 102 (when n=1)</p></li><li class="listitem"><p>GCC 3.4, GCC 4.x: 1000 + n (when n&gt;1) </p></li><li class="listitem"><p>GCC 3.4, GCC 4.x: 999999 (when n=0)</p></li></ul></div><p></p></li><li class="listitem"><p>Changes to the default compiler option for
 145     <code class="code">-fabi-version</code>.
 146     </p><p>
 147     It is versioned as follows:
 148     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0: (Error, not versioned) </p></li><li class="listitem"><p>GCC 3.1: (Error, not versioned) </p></li><li class="listitem"><p>GCC 3.2: <code class="code">-fabi-version=1</code></p></li><li class="listitem"><p>GCC 3.3: <code class="code">-fabi-version=1</code></p></li><li class="listitem"><p>GCC 3.4, GCC 4.x: <code class="code">-fabi-version=2</code> <span class="emphasis"><em>(Incompatible with previous)</em></span></p></li></ul></div><p></p></li><li class="listitem"><p>Incremental bumping of a library pre-defined macro. For releases
 149     before 3.4.0, the macro is __GLIBCPP__. For later releases, it's
 150     __GLIBCXX__. (The libstdc++ project generously changed from CPP to
 151     CXX throughout its source to allow the "C" pre-processor the CPP
 152     macro namespace.) These macros are defined as the date the library
 153     was released, in compressed ISO date format, as an unsigned long.
 154     </p><p>
 155     This macro is defined in the file "c++config" in the
 156     "libstdc++-v3/include/bits" directory. (Up to GCC 4.1.0, it was
 157     changed every night by an automated script. Since GCC 4.1.0, it is
 158     the same value as gcc/DATESTAMP.)
 159     </p><p>
 160     It is versioned as follows:
 161     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: 20010615</p></li><li class="listitem"><p>GCC 3.0.1: 20010819</p></li><li class="listitem"><p>GCC 3.0.2: 20011023</p></li><li class="listitem"><p>GCC 3.0.3: 20011220</p></li><li class="listitem"><p>GCC 3.0.4: 20020220</p></li><li class="listitem"><p>GCC 3.1.0: 20020514</p></li><li class="listitem"><p>GCC 3.1.1: 20020725</p></li><li class="listitem"><p>GCC 3.2.0: 20020814</p></li><li class="listitem"><p>GCC 3.2.1: 20021119</p></li><li class="listitem"><p>GCC 3.2.2: 20030205</p></li><li class="listitem"><p>GCC 3.2.3: 20030422</p></li><li class="listitem"><p>GCC 3.3.0: 20030513</p></li><li class="listitem"><p>GCC 3.3.1: 20030804</p></li><li class="listitem"><p>GCC 3.3.2: 20031016</p></li><li class="listitem"><p>GCC 3.3.3: 20040214</p></li><li class="listitem"><p>GCC 3.4.0: 20040419</p></li><li class="listitem"><p>GCC 3.4.1: 20040701</p></li><li class="listitem"><p>GCC 3.4.2: 20040906</p></li><li class="listitem"><p>GCC 3.4.3: 20041105</p></li><li class="listitem"><p>GCC 3.4.4: 20050519</p></li><li class="listitem"><p>GCC 3.4.5: 20051201</p></li><li class="listitem"><p>GCC 3.4.6: 20060306</p></li><li class="listitem"><p>GCC 4.0.0: 20050421</p></li><li class="listitem"><p>GCC 4.0.1: 20050707</p></li><li class="listitem"><p>GCC 4.0.2: 20050921</p></li><li class="listitem"><p>GCC 4.0.3: 20060309</p></li><li class="listitem"><p>GCC 4.1.0: 20060228</p></li><li class="listitem"><p>GCC 4.1.1: 20060524</p></li><li class="listitem"><p>GCC 4.1.2: 20070214</p></li><li class="listitem"><p>GCC 4.2.0: 20070514</p></li><li class="listitem"><p>GCC 4.2.1: 20070719</p></li><li class="listitem"><p>GCC 4.2.2: 20071007</p></li><li class="listitem"><p>GCC 4.2.3: 20080201</p></li><li class="listitem"><p>GCC 4.2.4: 20080519</p></li><li class="listitem"><p>GCC 4.3.0: 20080306</p></li><li class="listitem"><p>GCC 4.3.1: 20080606</p></li><li class="listitem"><p>GCC 4.3.2: 20080827</p></li><li class="listitem"><p>GCC 4.3.3: 20090124</p></li><li class="listitem"><p>GCC 4.3.4: 20090804</p></li><li class="listitem"><p>GCC 4.3.5: 20100522</p></li><li class="listitem"><p>GCC 4.3.6: 20110627</p></li><li class="listitem"><p>GCC 4.4.0: 20090421</p></li><li class="listitem"><p>GCC 4.4.1: 20090722</p></li><li class="listitem"><p>GCC 4.4.2: 20091015</p></li><li class="listitem"><p>GCC 4.4.3: 20100121</p></li><li class="listitem"><p>GCC 4.4.4: 20100429</p></li><li class="listitem"><p>GCC 4.4.5: 20101001</p></li><li class="listitem"><p>GCC 4.4.6: 20110416</p></li><li class="listitem"><p>GCC 4.4.7: 20120313</p></li><li class="listitem"><p>GCC 4.5.0: 20100414</p></li><li class="listitem"><p>GCC 4.5.1: 20100731</p></li><li class="listitem"><p>GCC 4.5.2: 20101216</p></li><li class="listitem"><p>GCC 4.5.3: 20110428</p></li><li class="listitem"><p>GCC 4.5.4: 20120702</p></li><li class="listitem"><p>GCC 4.6.0: 20110325</p></li><li class="listitem"><p>GCC 4.6.1: 20110627</p></li><li class="listitem"><p>GCC 4.6.2: 20111026</p></li><li class="listitem"><p>GCC 4.6.3: 20120301</p></li><li class="listitem"><p>GCC 4.7.0: 20120322</p></li><li class="listitem"><p>GCC 4.7.1: 20120614</p></li><li class="listitem"><p>GCC 4.7.2: 20120920</p></li></ul></div><p></p></li><li class="listitem"><p>
 162     Incremental bumping of a library pre-defined macro,
 163     _GLIBCPP_VERSION. This macro is defined as the released version of
 164     the library, as a string literal. This is only implemented in
 165     GCC 3.1.0 releases and higher, and is deprecated in 3.4 (where it
 166     is called _GLIBCXX_VERSION).
 167     </p><p>
 168     This macro is defined in the file "c++config" in the
 169     "libstdc++-v3/include/bits" directory and is generated
 170     automatically by autoconf as part of the configure-time generation
 171     of config.h.
 172     </p><p>
 173     It is versioned as follows:
 174     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: "3.0.0"</p></li><li class="listitem"><p>GCC 3.0.1: "3.0.0" (Error, should be "3.0.1")</p></li><li class="listitem"><p>GCC 3.0.2: "3.0.0" (Error, should be "3.0.2")</p></li><li class="listitem"><p>GCC 3.0.3: "3.0.0" (Error, should be "3.0.3")</p></li><li class="listitem"><p>GCC 3.0.4: "3.0.0" (Error, should be "3.0.4")</p></li><li class="listitem"><p>GCC 3.1.0: "3.1.0"</p></li><li class="listitem"><p>GCC 3.1.1: "3.1.1"</p></li><li class="listitem"><p>GCC 3.2.0: "3.2"</p></li><li class="listitem"><p>GCC 3.2.1: "3.2.1"</p></li><li class="listitem"><p>GCC 3.2.2: "3.2.2"</p></li><li class="listitem"><p>GCC 3.2.3: "3.2.3"</p></li><li class="listitem"><p>GCC 3.3.0: "3.3"</p></li><li class="listitem"><p>GCC 3.3.1: "3.3.1"</p></li><li class="listitem"><p>GCC 3.3.2: "3.3.2"</p></li><li class="listitem"><p>GCC 3.3.3: "3.3.3"</p></li><li class="listitem"><p>GCC 3.4: "version-unused"</p></li><li class="listitem"><p>GCC 4.x: "version-unused"</p></li></ul></div><p></p></li><li class="listitem"><p>
 175     Matching each specific C++ compiler release to a specific set of
 176     C++ include files. This is only implemented in GCC 3.1.1 releases
 177     and higher.
 178     </p><p>
 179     All C++ includes are installed in
 180     <code class="filename">include/c++</code>, then nest in a
 181     directory hierarchy corresponding to the C++ compiler's released
 182     version. This version corresponds to the variable "gcc_version" in
 183     "libstdc++-v3/acinclude.m4," and more details can be found in that
 184     file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before GCC 3.4.0).
 185     </p><p>
 186     C++ includes are versioned as follows:
 187     </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>GCC 3.0.0: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.1: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.2: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.3: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.4: include/g++-v3</p></li><li class="listitem"><p>GCC 3.1.0: include/g++-v3</p></li><li class="listitem"><p>GCC 3.1.1: include/c++/3.1.1</p></li><li class="listitem"><p>GCC 3.2.0: include/c++/3.2</p></li><li class="listitem"><p>GCC 3.2.1: include/c++/3.2.1</p></li><li class="listitem"><p>GCC 3.2.2: include/c++/3.2.2</p></li><li class="listitem"><p>GCC 3.2.3: include/c++/3.2.3</p></li><li class="listitem"><p>GCC 3.3.0: include/c++/3.3</p></li><li class="listitem"><p>GCC 3.3.1: include/c++/3.3.1</p></li><li class="listitem"><p>GCC 3.3.2: include/c++/3.3.2</p></li><li class="listitem"><p>GCC 3.3.3: include/c++/3.3.3</p></li><li class="listitem"><p>GCC 3.4.x: include/c++/3.4.x</p></li><li class="listitem"><p>GCC 4.x.y: include/c++/4.x.y</p></li></ul></div><p></p></li></ol></div><p>
 188   Taken together, these techniques can accurately specify interface
 189   and implementation changes in the GNU C++ tools themselves. Used
 190   properly, they allow both the GNU C++ tools implementation, and
 191   programs using them, an evolving yet controlled development that
 192   maintains backward compatibility.
 193 </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.prereq"></a>Prerequisites</h4></div></div></div><p>
 194       Minimum environment that supports a versioned ABI: A supported
 195       dynamic linker, a GNU linker of sufficient vintage to understand
 196       demangled C++ name globbing (ld) or the Sun linker, a shared
 197       executable compiled
 198       with g++, and shared libraries (libgcc_s, libstdc++) compiled by
 199       a compiler (g++) with a compatible ABI. Phew.
 200     </p><p>
 201       On top of all that, an additional constraint: libstdc++ did not
 202       attempt to version symbols (or age gracefully, really) until
 203       version 3.1.0.
 204     </p><p>
 205       Most modern GNU/Linux and BSD versions, particularly ones using
 206       GCC 3.1 and later, will meet the
 207       requirements above, as does Solaris 2.5 and up.
 208     </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.config"></a>Configuring</h4></div></div></div><p>
 209       It turns out that most of the configure options that change
 210       default behavior will impact the mangled names of exported
 211       symbols, and thus impact versioning and compatibility.
 212     </p><p>
 213       For more information on configure options, including ABI
 214       impacts, see:
 215       <a class="link" href="configure.html" title="Configure">here</a>
 216     </p><p>
 217       There is one flag that explicitly deals with symbol versioning:
 218       --enable-symvers.
 219     </p><p>
 220       In particular, libstdc++-v3/acinclude.m4 has a macro called
 221       GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument
 222       passed in via --enable-symvers=foo). At that point, the macro
 223       attempts to make sure that all the requirement for symbol
 224       versioning are in place. For more information, please consult
 225       acinclude.m4.
 226     </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.versioning.active"></a>Checking Active</h4></div></div></div><p>
 227       When the GNU C++ library is being built with symbol versioning
 228       on, you should see the following at configure time for
 229       libstdc++:
 230     </p><pre class="screen">
 231 <code class="computeroutput">
 232   checking versioning on shared library symbols... gnu
 233 </code>
 234 </pre><p>
 235   or another of the supported styles.
 236   If you don't see this line in the configure output, or if this line
 237   appears but the last word is 'no', then you are out of luck.
 238 </p><p>
 239   If the compiler is pre-installed, a quick way to test is to compile
 240   the following (or any) simple C++ file and link it to the shared
 241   libstdc++ library:
 242 </p><pre class="programlisting">
 243 #include &lt;iostream&gt;
 244
 245 int main()
 246 { std::cout &lt;&lt; "hello" &lt;&lt; std::endl; return 0; }
 247
 248 %g++ hello.cc -o hello.out
 249
 250 %ldd hello.out
 251         libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
 252         libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
 253         libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
 254         libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
 255         /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
 256
 257 %nm hello.out
 258 </pre><p>
 259 If you see symbols in the resulting output with "GLIBCXX_3" as part
 260 of the name, then the executable is versioned. Here's an example:
 261 </p><p>
 262    <code class="code">U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
 263 </p><p>
 264 On Solaris 2, you can use <code class="code">pvs -r</code> instead:
 265 </p><pre class="programlisting">
 266 %g++ hello.cc -o hello.out
 267
 268 %pvs -r hello.out
 269         libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12);
 270         libgcc_s.so.1 (GCC_3.0);
 271         libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
 272 </pre><p>
 273 <code class="code">ldd -v</code> works too, but is very verbose.
 274 </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_allowed"></a>Allowed Changes</h3></div></div></div><p>
 275 The following will cause the library minor version number to
 276 increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".
 277 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Adding an exported global or static data member</p></li><li class="listitem"><p>Adding an exported function, static or non-virtual member function</p></li><li class="listitem"><p>Adding an exported symbol or symbols by additional instantiations</p></li></ol></div><p>
 278 Other allowed changes are possible.
 279 </p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.changes_no"></a>Prohibited Changes</h3></div></div></div><p>
 280 The following non-exhaustive list will cause the library major version
 281 number to increase, say from "libstdc++.so.3.0.4" to
 282 "libstdc++.so.4.0.0".
 283 </p><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>Changes in the gcc/g++ compiler ABI</p></li><li class="listitem"><p>Changing size of an exported symbol</p></li><li class="listitem"><p>Changing alignment of an exported symbol</p></li><li class="listitem"><p>Changing the layout of an exported symbol</p></li><li class="listitem"><p>Changing mangling on an exported symbol</p></li><li class="listitem"><p>Deleting an exported symbol</p></li><li class="listitem"><p>Changing the inheritance properties of a type by adding or removing
 284     base classes</p></li><li class="listitem"><p>
 285   Changing the size, alignment, or layout of types
 286   specified in the C++ standard. These may not necessarily be
 287   instantiated or otherwise exported in the library binary, and
 288   include all the required locale facets, as well as things like
 289   std::basic_streambuf, et al.
 290 </p></li><li class="listitem"><p> Adding an explicit copy constructor or destructor to a
 291 class that would otherwise have implicit versions. This will change
 292 the way the compiler deals with this class in by-value return
 293 statements or parameters: instead of passing instances of this
 294 class in registers, the compiler will be forced to use memory. See the
 295 section on <a class="link" href="http://mentorembedded.github.com/cxx-abi/abi.html#calls" target="_top">Function
 296 Calling Conventions and APIs</a>
 297  of the C++ ABI documentation for further details.
 298 </p></li></ol></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.impl"></a>Implementation</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
 299      Separation of interface and implementation
 300    </p><p>
 301      This is accomplished by two techniques that separate the API from
 302      the ABI: forcing undefined references to link against a library
 303      binary for definitions.
 304    </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Include files have declarations, source files have defines</span></dt><dd><p>
 305         For non-templatized types, such as much of <code class="code">class
 306         locale</code>, the appropriate standard C++ include, say
 307         <code class="code">locale</code>, can contain full declarations, while
 308         various source files (say <code class="code"> locale.cc, locale_init.cc,
 309         localename.cc</code>) contain definitions.
 310       </p></dd><dt><span class="term">Extern template on required types</span></dt><dd><p>
 311        For parts of the standard that have an explicit list of
 312        required instantiations, the GNU extension syntax <code class="code"> extern
 313        template </code> can be used to control where template
 314        definitions reside. By marking required instantiations as
 315        <code class="code"> extern template </code> in include files, and providing
 316        explicit instantiations in the appropriate instantiation files,
 317        non-inlined template functions can be versioned. This technique
 318        is mostly used on parts of the standard that require <code class="code">
 319        char</code> and <code class="code"> wchar_t</code> instantiations, and
 320        includes <code class="code"> basic_string</code>, the locale facets, and the
 321        types in <code class="code"> iostreams</code>.
 322      </p></dd></dl></div><p>
 323    In addition, these techniques have the additional benefit that they
 324    reduce binary size, which can increase runtime performance.
 325  </p></li><li class="listitem"><p>
 326      Namespaces linking symbol definitions to export mapfiles
 327    </p><p>
 328      All symbols in the shared library binary are processed by a
 329      linker script at build time that either allows or disallows
 330      external linkage. Because of this, some symbols, regardless of
 331      normal C/C++ linkage, are not visible. Symbols that are internal
 332      have several appealing characteristics: by not exporting the
 333      symbols, there are no relocations when the shared library is
 334      started and thus this makes for faster runtime loading
 335      performance by the underlying dynamic loading mechanism. In
 336      addition, they have the possibility of changing without impacting
 337      ABI compatibility.
 338    </p><p>The following namespaces are transformed by the mapfile:</p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="code">namespace std</code></span></dt><dd><p> Defaults to exporting all symbols in label
 339 <code class="code">GLIBCXX</code> that do not begin with an underscore, i.e.,
 340 <code class="code">__test_func</code> would not be exported by default. Select
 341 exceptional symbols are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_cxx</code></span></dt><dd><p> Defaults to not exporting any symbols in label
 342 <code class="code">GLIBCXX</code>, select items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_internal</code></span></dt><dd><p> Defaults to not exported, no items are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __cxxabiv1</code>, aliased to <code class="code"> namespace abi</code></span></dt><dd><p> Defaults to not exporting any symbols in label
 343 <code class="code">CXXABI</code>, select items are allowed to be visible.</p></dd></dl></div><p>
 344 </p></li><li class="listitem"><p>Freezing the API</p><p>Disallowed changes, as above, are not made on a stable release
 345 branch. Enforcement tends to be less strict with GNU extensions that
 346 standard includes.</p></li></ol></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.testing"></a>Testing</h3></div></div></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.single"></a>Single ABI Testing</h4></div></div></div><p>
 347       Testing for GNU C++ ABI changes is composed of two distinct
 348       areas: testing the C++ compiler (g++) for compiler changes, and
 349       testing the C++ library (libstdc++) for library changes.
 350     </p><p>
 351       Testing the C++ compiler ABI can be done various ways.
 352     </p><p>
 353       One.  Intel ABI checker.
 354     </p><p>
 355 Two.
 356 The second is yet unreleased, but has been announced on the gcc
 357 mailing list. It is yet unspecified if these tools will be freely
 358 available, and able to be included in a GNU project. Please contact
 359 Mark Mitchell (mark@codesourcery.com) for more details, and current
 360 status.
 361 </p><p>
 362 Three.
 363 Involves using the vlad.consistency test framework. This has also been
 364 discussed on the gcc mailing lists.
 365 </p><p>
 366 Testing the C++ library ABI can also be done various ways.
 367 </p><p>
 368 One.
 369 (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
 370 one with a new compiler and an old library, and the other with an old
 371 compiler and a new library, and look for testsuite regressions)
 372 </p><p>
 373 Details on how to set this kind of test up can be found here:
 374 http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
 375 </p><p>
 376 Two.
 377 Use the 'make check-abi' rule in the libstdc++ Makefile.
 378 </p><p>
 379 This is a proactive check of the library ABI. Currently, exported symbol
 380 names that are either weak or defined are checked against a last known
 381 good baseline. Currently, this baseline is keyed off of 3.4.0
 382 binaries, as this was the last time the .so number was incremented. In
 383 addition, all exported names are demangled, and the exported objects
 384 are checked to make sure they are the same size as the same object in
 385 the baseline.
 386
 387 Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span>
 388 configured library and compiler: in particular, if options such as
 389 --enable-clocale, or --with-cpu, in case of multilibs, are used at
 390 configure time, the check may fail, either because of substantive
 391 differences or because of limitations of the current checking
 392 machinery.
 393 </p><p>
 394 This dataset is insufficient, yet a start. Also needed is a
 395 comprehensive check for all user-visible types part of the standard
 396 library for sizeof() and alignof() changes.
 397 </p><p>
 398 Verifying compatible layouts of objects is not even attempted.  It
 399 should be possible to use sizeof, alignof, and offsetof to compute
 400 offsets for each structure and type in the standard library, saving to
 401 another datafile. Then, compute this in a similar way for new
 402 binaries, and look for differences.
 403 </p><p>
 404 Another approach might be to use the -fdump-class-hierarchy flag to
 405 get information. However, currently this approach gives insufficient
 406 data for use in library testing, as class data members, their offsets,
 407 and other detailed data is not displayed with this flag.
 408 (See PR g++/7470 on how this was used to find bugs.)
 409 </p><p>
 410 Perhaps there are other C++ ABI checkers. If so, please notify
 411 us. We'd like to know about them!
 412 </p></div><div class="section"><div class="titlepage"><div><div><h4 class="title"><a id="abi.testing.multi"></a>Multiple ABI Testing</h4></div></div></div><p>
 413 A "C" application, dynamically linked to two shared libraries, liba,
 414 libb. The dependent library liba is a C++ shared library compiled with
 415 GCC 3.3, and uses io, exceptions, locale, etc. The dependent library
 416 libb is a C++ shared library compiled with GCC 3.4, and also uses io,
 417 exceptions, locale, etc.
 418 </p><p> As above, libone is constructed as follows: </p><pre class="programlisting">
 419 %$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc
 420
 421 %$bld/H-x86-gcc-3.4.0/bin/g++ -shared -Wl,-soname -Wl,libone.so.1 -Wl,-O1 -Wl,-z,defs a.o -o libone.so.1.0.0
 422
 423 %ln -s libone.so.1.0.0 libone.so
 424
 425 %$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
 426
 427 %ar cru libone.a a.o
 428 </pre><p> And, libtwo is constructed as follows: </p><pre class="programlisting">
 429 %$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc
 430
 431 %$bld/H-x86-gcc-3.3.3/bin/g++ -shared -Wl,-soname -Wl,libtwo.so.1 -Wl,-O1 -Wl,-z,defs b.o -o libtwo.so.1.0.0
 432
 433 %ln -s libtwo.so.1.0.0 libtwo.so
 434
 435 %$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
 436
 437 %ar cru libtwo.a b.o
 438 </pre><p> ...with the resulting libraries looking like </p><pre class="screen">
 439 <code class="computeroutput">
 440 %ldd libone.so.1.0.0
 441         libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40016000)
 442         libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400fa000)
 443         libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
 444         libc.so.6 =&gt; /lib/tls/libc.so.6 (0x40125000)
 445         /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
 446
 447 %ldd libtwo.so.1.0.0
 448         libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x40027000)
 449         libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400e1000)
 450         libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
 451         libc.so.6 =&gt; /lib/tls/libc.so.6 (0x4010c000)
 452         /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
 453 </code>
 454 </pre><p>
 455   Then, the "C" compiler is used to compile a source file that uses
 456   functions from each library.
 457 </p><pre class="programlisting">
 458 gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6
 459 </pre><p>
 460   Which gives the expected:
 461 </p><pre class="screen">
 462 <code class="computeroutput">
 463 %ldd a.out
 464         libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
 465         libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40015000)
 466         libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
 467         libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
 468         libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
 469         /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
 470 </code>
 471 </pre><p>
 472   This resulting binary, when executed, will be able to safely use
 473   code from both liba, and the dependent libstdc++.so.6, and libb,
 474   with the dependent libstdc++.so.5.
 475 </p></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="abi.issues"></a>Outstanding Issues</h3></div></div></div><p>
 476   Some features in the C++ language make versioning especially
 477   difficult. In particular, compiler generated constructs such as
 478   implicit instantiations for templates, typeinfo information, and
 479   virtual tables all may cause ABI leakage across shared library
 480   boundaries. Because of this, mixing C++ ABIs is not recommended at
 481   this time.
 482 </p><p>
 483   For more background on this issue, see these bugzilla entries:
 484 </p><p>
 485 <a class="link" href="http://gcc.gnu.org/PR24660" target="_top">24660: versioning weak symbols in libstdc++</a>
 486 </p><p>
 487 <a class="link" href="http://gcc.gnu.org/PR19664" target="_top">19664: libstdc++ headers should have pop/push of the visibility around the declarations</a>
 488 </p></div><div class="bibliography"><div class="titlepage"><div><div><h3 class="title"><a id="abi.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry"><a id="biblio.abicheck"></a><p>[biblio.abicheck] <span class="title"><em>
 489         <a class="link" href="http://abicheck.sourceforge.net" target="_top">
 490           ABIcheck
 491         </a>
 492       </em>. </span></p></div><div class="biblioentry"><a id="biblio.cxxabi"></a><p>[biblio.cxxabi] <span class="title"><em>
 493         <a class="link" href="http://www.codesourcery.com/cxx-abi/" target="_top">
 494           C++ ABI Summary
 495         </a>
 496       </em>. </span></p></div><div class="biblioentry"><a id="idm234595922544"></a><p><span class="title"><em>
 497         <a class="link" href="http://www.intel.com/cd/software/products/asmo-na/eng/284736.htm" target="_top">
 498         Intel Compilers for Linux Compatibility with the GNU Compilers
 499         </a>
 500       </em>. </span></p></div><div class="biblioentry"><a id="idm234595920688"></a><p><span class="title"><em>
 501         <a class="link" href="http://download.oracle.com/docs/cd/E19963-01/html/819-0690/index.html" target="_top">
 502         Linker and Libraries Guide (document 819-0690)
 503         </a>
 504       </em>. </span></p></div><div class="biblioentry"><a id="idm234595918848"></a><p><span class="title"><em>
 505         <a class="link" href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html" target="_top">
 506       Sun Studio 11: C++ Migration Guide (document 819-3689)
 507         </a>
 508       </em>. </span></p></div><div class="biblioentry"><a id="idm234595916992"></a><p><span class="title"><em>
 509         <a class="link" href="http://www.akkadia.org/drepper/dsohowto.pdf" target="_top">
 510       How to Write Shared Libraries
 511         </a>
 512       </em>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span></p></div><div class="biblioentry"><a id="idm234595913552"></a><p><span class="title"><em>
 513         <a class="link" href="http://www.arm.com/miscPDFs/8033.pdf" target="_top">
 514       C++ ABI for the ARM Architecture
 515         </a>
 516       </em>. </span></p></div><div class="biblioentry"><a id="idm234595911744"></a><p><span class="title"><em>
 517         <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html" target="_top">
 518       Dynamic Shared Objects: Survey and Issues
 519         </a>
 520       </em>. </span><span class="subtitle">
 521       ISO C++ J16/06-0046
 522     . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span></p></div><div class="biblioentry"><a id="idm234595908448"></a><p><span class="title"><em>
 523         <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html" target="_top">
 524         Versioning With Namespaces
 525         </a>
 526       </em>. </span><span class="subtitle">
 527       ISO C++ J16/06-0083
 528     . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span></p></div><div class="biblioentry"><a id="idm234595905168"></a><p><span class="title"><em>
 529         <a class="link" href="http://syrcose.ispras.ru/2009/files/SYRCoSE2009-CfP.pdf" target="_top">
 530       Binary Compatibility of Shared Libraries Implemented in C++
 531       on GNU/Linux Systems
 532         </a>
 533       </em>. </span><span class="subtitle">
 534       SYRCoSE 2009
 535     . </span><span class="author"><span class="firstname">Pavel</span> <span class="surname">Shved</span>. </span><span class="author"><span class="firstname">Denis</span> <span class="surname">Silakov</span>. </span></p></div></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="test.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="appendix_porting.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">Test </td><td width="20%" align="center"><a accesskey="h" href="../index.html">Home</a></td><td width="40%" align="right" valign="top"> API Evolution and Deprecation History</td></tr></table></div></body></html>