xref: /netbsd-src/external/gpl3/gcc/dist/libstdc++-v3/doc/html/manual/abi.html (revision 3f4ceed98fffd10d8f2ada3ccdb32adaf619f42c) 
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.io/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&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 set
158    during configuration to the same value as
159    <code class="filename">gcc/DATESTAMP</code>, so for an official release its value
160    is the same as the date of the release, which is given in the <a class="link" href="https://gcc.gnu.org/develop.html#timeline" target="_top">GCC Release
161    Timeline</a>.
162    </p><p>
163    This macro is not useful for determining whether a particular feature is
164    supported by the version of libstdc++ you are using. The date of a release
165    might be after a feature was added to the development trunk, but the
166    release could be from an older branch. For example, in the 5.4.0 release
167    the macro has the value 20160603 which is greater than the 20160427 value
168    of the macro in the 6.1.0 release, but there are features supported in the
169    6.1.0 release that are not supported in 5.4.0 release.
170    You also can't test for the exact values listed below to try and
171    identify a release, because a snapshot taken from the gcc-5-branch on
172    2016-04-27 would have the same value for the macro as the 6.1.0 release
173    despite being a different version.
174    Many GNU/Linux distributions build their GCC packages from snapshots, so
175    the macro can have dates that doesn't correspond to official releases.
176    </p><p>
177    It is versioned as follows:
178    </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>
179      GCC 4.1.0 and later: the GCC release date, as shown in the
180      <a class="link" href="https://gcc.gnu.org/develop.html#timeline" target="_top">GCC
181      Release Timeline</a>
182    </p></li></ul></div><p></p></li><li class="listitem"><p>
183    Incremental bumping of a library pre-defined macro,
184    _GLIBCPP_VERSION. This macro is defined as the released version of
185    the library, as a string literal. This is only implemented in
186    GCC 3.1.0 releases and higher, and is deprecated in 3.4 (where it
187    is called _GLIBCXX_VERSION).
188    </p><p>
189    This macro is defined in the file "c++config" in the
190    "libstdc++-v3/include/bits" directory and is generated
191    automatically by autoconf as part of the configure-time generation
192    of config.h.
193    </p><p>
194    It is versioned as follows:
195    </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>
196    Matching each specific C++ compiler release to a specific set of
197    C++ include files. This is only implemented in GCC 3.1.1 releases
198    and higher.
199    </p><p>
200    All C++ includes are installed in
201    <code class="filename">include/c++</code>, then nest in a
202    directory hierarchy corresponding to the C++ compiler's released
203    version. This version corresponds to the variable "gcc_version" in
204    "libstdc++-v3/acinclude.m4," and more details can be found in that
205    file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before GCC 3.4.0).
206    </p><p>
207    C++ includes are versioned as follows:
208    </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>
209  Taken together, these techniques can accurately specify interface
210  and implementation changes in the GNU C++ tools themselves. Used
211  properly, they allow both the GNU C++ tools implementation, and
212  programs using them, an evolving yet controlled development that
213  maintains backward compatibility.
214</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>
215      Minimum environment that supports a versioned ABI: A supported
216      dynamic linker, a GNU linker of sufficient vintage to understand
217      demangled C++ name globbing (ld) or the Sun linker, a shared
218      executable compiled
219      with g++, and shared libraries (libgcc_s, libstdc++) compiled by
220      a compiler (g++) with a compatible ABI. Phew.
221    </p><p>
222      On top of all that, an additional constraint: libstdc++ did not
223      attempt to version symbols (or age gracefully, really) until
224      version 3.1.0.
225    </p><p>
226      Most modern GNU/Linux and BSD versions, particularly ones using
227      GCC 3.1 and later, will meet the
228      requirements above, as does Solaris 2.5 and up.
229    </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>
230      It turns out that most of the configure options that change
231      default behavior will impact the mangled names of exported
232      symbols, and thus impact versioning and compatibility.
233    </p><p>
234      For more information on configure options, including ABI
235      impacts, see:
236      <a class="link" href="configure.html" title="Configure">here</a>
237    </p><p>
238      There is one flag that explicitly deals with symbol versioning:
239      --enable-symvers.
240    </p><p>
241      In particular, libstdc++-v3/acinclude.m4 has a macro called
242      GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument
243      passed in via --enable-symvers=foo). At that point, the macro
244      attempts to make sure that all the requirement for symbol
245      versioning are in place. For more information, please consult
246      acinclude.m4.
247    </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>
248      When the GNU C++ library is being built with symbol versioning
249      on, you should see the following at configure time for
250      libstdc++ (showing either 'gnu' or another of the supported styles):
251    </p><pre class="screen">
252<code class="computeroutput">
253  checking versioning on shared library symbols... gnu
254</code>
255</pre><p>
256  If you don't see this line in the configure output, or if this line
257  appears but the last word is 'no', then you are out of luck.
258</p><p>
259  If the compiler is pre-installed, a quick way to test is to compile
260  the following (or any) simple C++ file and link it to the shared
261  libstdc++ library:
262</p><pre class="programlisting">
263#include &lt;iostream&gt;
264
265int main()
266{ std::cout &lt;&lt; "hello" &lt;&lt; std::endl; return 0; }
267
268%g++ hello.cc -o hello.out
269
270%ldd hello.out
271	libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
272	libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
273	libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
274	libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
275	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
276
277%nm hello.out
278</pre><p>
279If you see symbols in the resulting output with "GLIBCXX_3" as part
280of the name, then the executable is versioned. Here's an example:
281</p><p>
282   <code class="code">U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
283</p><p>
284On Solaris 2, you can use <code class="code">pvs -r</code> instead:
285</p><pre class="programlisting">
286%g++ hello.cc -o hello.out
287
288%pvs -r hello.out
289        libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12);
290        libgcc_s.so.1 (GCC_3.0);
291        libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
292</pre><p>
293<code class="code">ldd -v</code> works too, but is very verbose.
294</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>
295The following will cause the library minor version number to
296increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".
297</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>
298Other allowed changes are possible.
299</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>
300The following non-exhaustive list will cause the library major version
301number to increase, say from "libstdc++.so.3.0.4" to
302"libstdc++.so.4.0.0".
303</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
304    base classes</p></li><li class="listitem"><p>
305  Changing the size, alignment, or layout of types
306  specified in the C++ standard. These may not necessarily be
307  instantiated or otherwise exported in the library binary, and
308  include all the required locale facets, as well as things like
309  std::basic_streambuf, et al.
310</p></li><li class="listitem"><p> Adding an explicit copy constructor or destructor to a
311class that would otherwise have implicit versions. This will change
312the way the compiler deals with this class in by-value return
313statements or parameters: instead of passing instances of this
314class in registers, the compiler will be forced to use memory. See the
315section on <a class="link" href="http://mentorembedded.github.io/cxx-abi/abi.html#calls" target="_top">Function
316Calling Conventions and APIs</a>
317 of the C++ ABI documentation for further details.
318</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>
319     Separation of interface and implementation
320   </p><p>
321     This is accomplished by two techniques that separate the API from
322     the ABI: forcing undefined references to link against a library
323     binary for definitions.
324   </p><div class="variablelist"><dl class="variablelist"><dt><span class="term">Include files have declarations, source files have defines</span></dt><dd><p>
325	For non-templatized types, such as much of <code class="code">class
326	locale</code>, the appropriate standard C++ include, say
327	<code class="code">locale</code>, can contain full declarations, while
328	various source files (say <code class="code"> locale.cc, locale_init.cc,
329	localename.cc</code>) contain definitions.
330      </p></dd><dt><span class="term">Extern template on required types</span></dt><dd><p>
331       For parts of the standard that have an explicit list of
332       required instantiations, the GNU extension syntax <code class="code"> extern
333       template </code> can be used to control where template
334       definitions reside. By marking required instantiations as
335       <code class="code"> extern template </code> in include files, and providing
336       explicit instantiations in the appropriate instantiation files,
337       non-inlined template functions can be versioned. This technique
338       is mostly used on parts of the standard that require <code class="code">
339       char</code> and <code class="code"> wchar_t</code> instantiations, and
340       includes <code class="code"> basic_string</code>, the locale facets, and the
341       types in <code class="code"> iostreams</code>.
342     </p></dd></dl></div><p>
343   In addition, these techniques have the additional benefit that they
344   reduce binary size, which can increase runtime performance.
345 </p></li><li class="listitem"><p>
346     Namespaces linking symbol definitions to export mapfiles
347   </p><p>
348     All symbols in the shared library binary are processed by a
349     linker script at build time that either allows or disallows
350     external linkage. Because of this, some symbols, regardless of
351     normal C/C++ linkage, are not visible. Symbols that are internal
352     have several appealing characteristics: by not exporting the
353     symbols, there are no relocations when the shared library is
354     started and thus this makes for faster runtime loading
355     performance by the underlying dynamic loading mechanism. In
356     addition, they have the possibility of changing without impacting
357     ABI compatibility.
358   </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
359<code class="code">GLIBCXX</code> that do not begin with an underscore, i.e.,
360<code class="code">__test_func</code> would not be exported by default. Select
361exceptional 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
362<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
363<code class="code">CXXABI</code>, select items are allowed to be visible.</p></dd></dl></div><p>
364</p></li><li class="listitem"><p>Freezing the API</p><p>Disallowed changes, as above, are not made on a stable release
365branch. Enforcement tends to be less strict with GNU extensions that
366standard 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>
367      Testing for GNU C++ ABI changes is composed of two distinct
368      areas: testing the C++ compiler (g++) for compiler changes, and
369      testing the C++ library (libstdc++) for library changes.
370    </p><p>
371      Testing the C++ compiler ABI can be done various ways.
372    </p><p>
373      One.  Intel ABI checker.
374    </p><p>
375Two.
376The second is yet unreleased, but has been announced on the gcc
377mailing list. It is yet unspecified if these tools will be freely
378available, and able to be included in a GNU project. Please contact
379Mark Mitchell (mark@codesourcery.com) for more details, and current
380status.
381</p><p>
382Three.
383Involves using the vlad.consistency test framework. This has also been
384discussed on the gcc mailing lists.
385</p><p>
386Testing the C++ library ABI can also be done various ways.
387</p><p>
388One.
389(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
390one with a new compiler and an old library, and the other with an old
391compiler and a new library, and look for testsuite regressions)
392</p><p>
393Details on how to set this kind of test up can be found here:
394http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
395</p><p>
396Two.
397Use the 'make check-abi' rule in the libstdc++ Makefile.
398</p><p>
399This is a proactive check of the library ABI. Currently, exported symbol
400names that are either weak or defined are checked against a last known
401good baseline. Currently, this baseline is keyed off of 3.4.0
402binaries, as this was the last time the .so number was incremented. In
403addition, all exported names are demangled, and the exported objects
404are checked to make sure they are the same size as the same object in
405the baseline.
406
407Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span>
408configured library and compiler: in particular, if options such as
409--enable-clocale, or --with-cpu, in case of multilibs, are used at
410configure time, the check may fail, either because of substantive
411differences or because of limitations of the current checking
412machinery.
413</p><p>
414This dataset is insufficient, yet a start. Also needed is a
415comprehensive check for all user-visible types part of the standard
416library for sizeof() and alignof() changes.
417</p><p>
418Verifying compatible layouts of objects is not even attempted.  It
419should be possible to use sizeof, alignof, and offsetof to compute
420offsets for each structure and type in the standard library, saving to
421another datafile. Then, compute this in a similar way for new
422binaries, and look for differences.
423</p><p>
424Another approach might be to use the -fdump-class-hierarchy flag to
425get information. However, currently this approach gives insufficient
426data for use in library testing, as class data members, their offsets,
427and other detailed data is not displayed with this flag.
428(See PR g++/7470 on how this was used to find bugs.)
429</p><p>
430Perhaps there are other C++ ABI checkers. If so, please notify
431us. We'd like to know about them!
432</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>
433A "C" application, dynamically linked to two shared libraries, liba,
434libb. The dependent library liba is a C++ shared library compiled with
435GCC 3.3, and uses io, exceptions, locale, etc. The dependent library
436libb is a C++ shared library compiled with GCC 3.4, and also uses io,
437exceptions, locale, etc.
438</p><p> As above, libone is constructed as follows: </p><pre class="programlisting">
439%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc
440
441%$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
442
443%ln -s libone.so.1.0.0 libone.so
444
445%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
446
447%ar cru libone.a a.o
448</pre><p> And, libtwo is constructed as follows: </p><pre class="programlisting">
449%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc
450
451%$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
452
453%ln -s libtwo.so.1.0.0 libtwo.so
454
455%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
456
457%ar cru libtwo.a b.o
458</pre><p> ...with the resulting libraries looking like </p><pre class="screen">
459<code class="computeroutput">
460%ldd libone.so.1.0.0
461	libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40016000)
462	libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400fa000)
463	libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
464	libc.so.6 =&gt; /lib/tls/libc.so.6 (0x40125000)
465	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
466
467%ldd libtwo.so.1.0.0
468	libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x40027000)
469	libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400e1000)
470	libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
471	libc.so.6 =&gt; /lib/tls/libc.so.6 (0x4010c000)
472	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
473</code>
474</pre><p>
475  Then, the "C" compiler is used to compile a source file that uses
476  functions from each library.
477</p><pre class="programlisting">
478gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6
479</pre><p>
480  Which gives the expected:
481</p><pre class="screen">
482<code class="computeroutput">
483%ldd a.out
484	libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
485	libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40015000)
486	libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
487	libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
488	libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
489	/lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
490</code>
491</pre><p>
492  This resulting binary, when executed, will be able to safely use
493  code from both liba, and the dependent libstdc++.so.6, and libb,
494  with the dependent libstdc++.so.5.
495</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>
496  Some features in the C++ language make versioning especially
497  difficult. In particular, compiler generated constructs such as
498  implicit instantiations for templates, typeinfo information, and
499  virtual tables all may cause ABI leakage across shared library
500  boundaries. Because of this, mixing C++ ABIs is not recommended at
501  this time.
502</p><p>
503  For more background on this issue, see these bugzilla entries:
504</p><p>
505<a class="link" href="http://gcc.gnu.org/PR24660" target="_top">24660: versioning weak symbols in libstdc++</a>
506</p><p>
507<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>
508</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>
509	<a class="link" href="http://abicheck.sourceforge.net" target="_top">
510	  ABIcheck
511	</a>
512      </em>. </span></p></div><div class="biblioentry"><a id="biblio.cxxabi"></a><p>[biblio.cxxabi] <span class="title"><em>
513	<a class="link" href="http://mentorembedded.github.io/cxx-abi/" target="_top">
514	  C++ ABI Summary
515	</a>
516      </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.4"></a><p><span class="title"><em>
517	<a class="link" href="https://software.intel.com/en-us/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers" target="_top">
518	Intel Compilers for Linux: Compatibility with GNU Compilers
519	</a>
520      </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.5"></a><p><span class="title"><em>
521	<a class="link" href="http://docs.oracle.com/cd/E23824_01/html/819-0690/index.html" target="_top">
522	Linker and Libraries Guide (document 819-0690)
523	</a>
524      </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.6"></a><p><span class="title"><em>
525	<a class="link" href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html" target="_top">
526      Sun Studio 11: C++ Migration Guide (document 819-3689)
527	</a>
528      </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.7"></a><p><span class="title"><em>
529	<a class="link" href="http://www.akkadia.org/drepper/dsohowto.pdf" target="_top">
530      How to Write Shared Libraries
531	</a>
532      </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>
533	<a class="link" href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0036b/index.html" target="_top">
534      C++ ABI for the ARM Architecture
535	</a>
536      </em>. </span></p></div><div class="biblioentry"><a id="id-1.3.6.3.6.10.9"></a><p><span class="title"><em>
537	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html" target="_top">
538      Dynamic Shared Objects: Survey and Issues
539	</a>
540      </em>. </span><span class="subtitle">
541      ISO C++ J16/06-0046
542    . </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>
543	<a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html" target="_top">
544	Versioning With Namespaces
545	</a>
546      </em>. </span><span class="subtitle">
547      ISO C++ J16/06-0083
548    . </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>
549	<a class="link" href="http://syrcose.ispras.ru/2009/files/02_paper.pdf" target="_top">
550      Binary Compatibility of Shared Libraries Implemented in C++
551      on GNU/Linux Systems
552	</a>
553      </em>. </span><span class="subtitle">
554      SYRCoSE 2009
555    . </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>