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 41Library ABI, which is the compilation of a given library API by a 42given 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 61C++ toolchain. With each release, various details have been changed so 62as 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 64releases of library binaries the ability to add new symbols and add 65functionality, all the while retaining compatibility with the previous 66releases in the series. Thus, program binaries linked with the initial 67release of a library binary will still run correctly if the library 68binary is replaced by carefully-managed subsequent library 69binaries. This is called forward compatibility. 70</p><p> 71The reverse (backwards compatibility) is not true. It is not possible 72to take program binaries linked with the latest version of a library 73binary in a release series (with additional symbols added), substitute 74in the initial release of the library binary, and remain link 75compatible. 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><li class="listitem"><p>GCC 5.1.0: libstdc++.so.6.0.21</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><li class="listitem"><p>GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9</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>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><li class="listitem"><p>GCC 5.x.0: include/c++/5.x.0</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 <iostream> 244 245int main() 246{ std::cout << "hello" << std::endl; return 0; } 247 248%g++ hello.cc -o hello.out 249 250%ldd hello.out 251 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) 252 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 253 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000) 254 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 255 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 256 257%nm hello.out 258</pre><p> 259If you see symbols in the resulting output with "GLIBCXX_3" as part 260of 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> 264On 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> 275The following will cause the library minor version number to 276increase, 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> 278Other 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> 280The following non-exhaustive list will cause the library major version 281number 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 291class that would otherwise have implicit versions. This will change 292the way the compiler deals with this class in by-value return 293statements or parameters: instead of passing instances of this 294class in registers, the compiler will be forced to use memory. See the 295section on <a class="link" href="http://mentorembedded.github.com/cxx-abi/abi.html#calls" target="_top">Function 296Calling 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 341exceptional 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 345branch. Enforcement tends to be less strict with GNU extensions that 346standard 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> 355Two. 356The second is yet unreleased, but has been announced on the gcc 357mailing list. It is yet unspecified if these tools will be freely 358available, and able to be included in a GNU project. Please contact 359Mark Mitchell (mark@codesourcery.com) for more details, and current 360status. 361</p><p> 362Three. 363Involves using the vlad.consistency test framework. This has also been 364discussed on the gcc mailing lists. 365</p><p> 366Testing the C++ library ABI can also be done various ways. 367</p><p> 368One. 369(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 370one with a new compiler and an old library, and the other with an old 371compiler and a new library, and look for testsuite regressions) 372</p><p> 373Details on how to set this kind of test up can be found here: 374http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html 375</p><p> 376Two. 377Use the 'make check-abi' rule in the libstdc++ Makefile. 378</p><p> 379This is a proactive check of the library ABI. Currently, exported symbol 380names that are either weak or defined are checked against a last known 381good baseline. Currently, this baseline is keyed off of 3.4.0 382binaries, as this was the last time the .so number was incremented. In 383addition, all exported names are demangled, and the exported objects 384are checked to make sure they are the same size as the same object in 385the baseline. 386 387Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span> 388configured library and compiler: in particular, if options such as 389--enable-clocale, or --with-cpu, in case of multilibs, are used at 390configure time, the check may fail, either because of substantive 391differences or because of limitations of the current checking 392machinery. 393</p><p> 394This dataset is insufficient, yet a start. Also needed is a 395comprehensive check for all user-visible types part of the standard 396library for sizeof() and alignof() changes. 397</p><p> 398Verifying compatible layouts of objects is not even attempted. It 399should be possible to use sizeof, alignof, and offsetof to compute 400offsets for each structure and type in the standard library, saving to 401another datafile. Then, compute this in a similar way for new 402binaries, and look for differences. 403</p><p> 404Another approach might be to use the -fdump-class-hierarchy flag to 405get information. However, currently this approach gives insufficient 406data for use in library testing, as class data members, their offsets, 407and 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> 410Perhaps there are other C++ ABI checkers. If so, please notify 411us. 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> 413A "C" application, dynamically linked to two shared libraries, liba, 414libb. The dependent library liba is a C++ shared library compiled with 415GCC 3.3, and uses io, exceptions, locale, etc. The dependent library 416libb is a C++ shared library compiled with GCC 3.4, and also uses io, 417exceptions, 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 => /usr/lib/libstdc++.so.6 (0x40016000) 442 libm.so.6 => /lib/tls/libm.so.6 (0x400fa000) 443 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000) 444 libc.so.6 => /lib/tls/libc.so.6 (0x40125000) 445 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 446 447%ldd libtwo.so.1.0.0 448 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000) 449 libm.so.6 => /lib/tls/libm.so.6 (0x400e1000) 450 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000) 451 libc.so.6 => /lib/tls/libc.so.6 (0x4010c000) 452 /lib/ld-linux.so.2 => /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"> 458gcc 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 => /usr/lib/libstdc++.so.5 (0x00764000) 465 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000) 466 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 467 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 468 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000) 469 /lib/ld-linux.so.2 => /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="id-1.3.6.3.6.10.4"></a><p><span class="title"><em> 497 <a class="link" href="https://software.intel.com/en-us/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers" target="_top"> 498 Intel Compilers for Linux: Compatibility with GNU Compilers 499 </a> 500 </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.5"></a><p><span class="title"><em> 501 <a class="link" href="http://docs.oracle.com/cd/E23824_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="id-1.3.6.3.6.10.6"></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="id-1.3.6.3.6.10.7"></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="id-1.3.6.3.6.10.8"></a><p><span class="title"><em> 513 <a class="link" href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0036b/index.html" target="_top"> 514 C++ ABI for the ARM Architecture 515 </a> 516 </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.9"></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="id-1.3.6.3.6.10.10"></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="id-1.3.6.3.6.10.11"></a><p><span class="title"><em> 529 <a class="link" href="http://syrcose.ispras.ru/2009/files/02_paper.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>