*: Regenerate.
[gcc.git] / libstdc++-v3 / doc / html / manual / abi.html
1 <html><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.76.1"><meta name="keywords" content="
2 C++
3 ,
4 ABI
5 ,
6 version
7 ,
8 dynamic
9 ,
10 shared
11 ,
12 compatibility
13 "><meta name="keywords" content="
14 ISO C++
15 ,
16 library
17 "><meta name="keywords" content="
18 ISO C++
19 ,
20 runtime
21 ,
22 library
23 "><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 bgcolor="white" text="black" link="#0000FF" vlink="#840084" alink="#0000FF"><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. 
24 Porting and Maintenance
25
26 </th><td width="20%" align="right"> <a accesskey="n" href="api.html">Next</a></td></tr></table><hr></div><div class="section" title="ABI Policy and Guidelines"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a name="appendix.porting.abi"></a>ABI Policy and Guidelines</h2></div></div></div><p>
27 </p><div class="section" title="The C++ Interface"><div class="titlepage"><div><div><h3 class="title"><a name="abi.cxx_interface"></a>The C++ Interface</h3></div></div></div><p>
28 C++ applications often depend on specific language support
29 routines, say for throwing exceptions, or catching exceptions, and
30 perhaps also depend on features in the C++ Standard Library.
31 </p><p>
32 The C++ Standard Library has many include files, types defined in
33 those include files, specific named functions, and other
34 behavior. The text of these behaviors, as written in source include
35 files, is called the Application Programing Interface, or API.
36 </p><p>
37 Furthermore, C++ source that is compiled into object files is
38 transformed by the compiler: it arranges objects with specific
39 alignment and in a particular layout, mangling names according to a
40 well-defined algorithm, has specific arrangements for the support of
41 virtual functions, etc. These details are defined as the compiler
42 Application Binary Interface, or ABI. The GNU C++ compiler uses an
43 industry-standard C++ ABI starting with version 3. Details can be
44 found in the <a class="link" href="http://www.codesourcery.com/public/cxx-abi/abi.html" target="_top">ABI
45 specification</a>.
46 </p><p>
47 The GNU C++ compiler, g++, has a compiler command line option to
48 switch between various different C++ ABIs. This explicit version
49 switch is the flag <code class="code">-fabi-version</code>. In addition, some
50 g++ command line options may change the ABI as a side-effect of
51 use. Such flags include <code class="code">-fpack-struct</code> and
52 <code class="code">-fno-exceptions</code>, but include others: see the complete
53 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
54 for Code Generation Conventions</a>.
55 </p><p>
56 The configure options used when building a specific libstdc++
57 version may also impact the resulting library ABI. The available
58 configure options, and their impact on the library ABI, are
59 documented
60 <a class="link" href="configure.html" title="Configure">here</a>.
61 </p><p> Putting all of these ideas together results in the C++ Standard
62 library ABI, which is the compilation of a given library API by a
63 given compiler ABI. In a nutshell:
64 </p><p>
65 <span class="quote"><span class="quote">
66 library API + compiler ABI = library ABI
67 </span></span>
68 </p><p>
69 The library ABI is mostly of interest for end-users who have
70 unresolved symbols and are linking dynamically to the C++ Standard
71 library, and who thus must be careful to compile their application
72 with a compiler that is compatible with the available C++ Standard
73 library binary. In this case, compatible is defined with the equation
74 above: given an application compiled with a given compiler ABI and
75 library API, it will work correctly with a Standard C++ Library
76 created with the same constraints.
77 </p><p>
78 To use a specific version of the C++ ABI, one must use a
79 corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that
80 implements the C++ ABI in question.
81 </p></div><div class="section" title="Versioning"><div class="titlepage"><div><div><h3 class="title"><a name="abi.versioning"></a>Versioning</h3></div></div></div><p> The C++ interface has evolved throughout the history of the GNU
82 C++ toolchain. With each release, various details have been changed so
83 as to give distinct versions to the C++ interface.
84 </p><div class="section" title="Goals"><div class="titlepage"><div><div><h4 class="title"><a name="abi.versioning.goals"></a>Goals</h4></div></div></div><p>Extending existing, stable ABIs. Versioning gives subsequent
85 releases of library binaries the ability to add new symbols and add
86 functionality, all the while retaining compatibility with the previous
87 releases in the series. Thus, program binaries linked with the initial
88 release of a library binary will still run correctly if the library
89 binary is replaced by carefully-managed subsequent library
90 binaries. This is called forward compatibility.
91 </p><p>
92 The reverse (backwards compatibility) is not true. It is not possible
93 to take program binaries linked with the latest version of a library
94 binary in a release series (with additional symbols added), substitute
95 in the initial release of the library binary, and remain link
96 compatible.
97 </p><p>Allows multiple, incompatible ABIs to coexist at the same time.
98 </p></div><div class="section" title="History"><div class="titlepage"><div><div><h4 class="title"><a name="abi.versioning.history"></a>History</h4></div></div></div><p>
99 How can this complexity be managed? What does C++ versioning mean?
100 Because library and compiler changes often make binaries compiled
101 with one version of the GNU tools incompatible with binaries
102 compiled with other (either newer or older) versions of the same GNU
103 tools, specific techniques are used to make managing this complexity
104 easier.
105 </p><p>
106 The following techniques are used:
107 </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
108 <code class="constant">DT_SONAME</code> mechanism (at least on ELF
109 systems). It is versioned as follows:
110 </p><div class="itemizedlist"><ul class="itemizedlist" 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" type="disc"><li class="listitem"><p>GCC 3.4, GCC 4.x: libgcc_s.so.1
111 when configuring <code class="code">--with-sjlj-exceptions</code>, or
112 libgcc_s.so.2 </p></li></ul></div><p>For hppa-linux the versions differ as follows: </p><div class="itemizedlist"><ul class="itemizedlist" type="disc"><li class="listitem"><p>GCC 3.4, GCC 4.[0-1]: either libgcc_s.so.1
113 when configuring <code class="code">--with-sjlj-exceptions</code>, or
114 libgcc_s.so.2 </p></li><li class="listitem"><p>GCC 4.[2-7]: either libgcc_s.so.3 when configuring
115 <code class="code">--with-sjlj-exceptions</code>) or libgcc_s.so.4
116 </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
117 definitions, where the version definition is the maximum for a
118 particular release. Labels are cumulative. If a particular release
119 is not listed, it has the same version labels as the preceding
120 release.</p><p>This corresponds to the mapfile: gcc/libgcc-std.ver</p><div class="itemizedlist"><ul class="itemizedlist" 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></ul></div></li><li class="listitem"><p>
121 Release versioning on the libstdc++.so binary, implemented in
122 the same way as the libgcc_s.so binary above. Listed is the
123 filename: <code class="constant">DT_SONAME</code> can be deduced from
124 the filename by removing the last two period-delimited numbers. For
125 example, filename <code class="filename">libstdc++.so.5.0.4</code>
126 corresponds to a <code class="constant">DT_SONAME</code> of
127 <code class="constant">libstdc++.so.5</code>. Binaries with equivalent
128 <code class="constant">DT_SONAME</code>s are forward-compatibile: in
129 the table below, releases incompatible with the previous
130 one are explicitly noted.
131 If a particular release is not listed, its libstdc++.so binary
132 has the same filename and <code class="constant">DT_SONAME</code> as the
133 preceding release.
134 </p><p>It is versioned as follows:
135 </p><div class="itemizedlist"><ul class="itemizedlist" 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></ul></div><p>
136 Note 1: Error should be libstdc++.so.3.0.3.
137 </p><p>
138 Note 2: Not strictly required.
139 </p><p>
140 Note 3: This release (but not previous or subsequent) has one
141 known incompatibility, see <a class="link" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678" target="_top">33678</a>
142 in the GCC bug database.
143 </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
144 definitions, where the version definition is the maximum for a
145 particular release. Note, only symbols which are newly introduced
146 will use the maximum version definition. Thus, for release series
147 with the same label, but incremented version definitions, the later
148 release has both versions. (An example of this would be the
149 GCC 3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and
150 GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0
151 release.) If a particular release is not listed, it has the same
152 version labels as the preceding release.
153 </p><div class="itemizedlist"><ul class="itemizedlist" 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></ul></div></li><li class="listitem"><p>Incremental bumping of a compiler pre-defined macro,
154 __GXX_ABI_VERSION. This macro is defined as the version of the
155 compiler v3 ABI, with g++ 3.0 being version 100. This macro will
156 be automatically defined whenever g++ is used (the curious can
157 test this by invoking g++ with the '-v' flag.)
158 </p><p>
159 This macro was defined in the file "lang-specs.h" in the gcc/cp directory.
160 Later versions defined it in "c-common.c" in the gcc directory, and from
161 G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the
162 '-fabi-version' command line option.
163 </p><p>
164 It is versioned as follows, where 'n' is given by '-fabi-version=n':
165 </p><div class="itemizedlist"><ul class="itemizedlist" 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
166 <code class="code">-fabi-version</code>.
167 </p><p>
168 It is versioned as follows:
169 </p><div class="itemizedlist"><ul class="itemizedlist" 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
170 before 3.4.0, the macro is __GLIBCPP__. For later releases, it's
171 __GLIBCXX__. (The libstdc++ project generously changed from CPP to
172 CXX throughout its source to allow the "C" pre-processor the CPP
173 macro namespace.) These macros are defined as the date the library
174 was released, in compressed ISO date format, as an unsigned long.
175 </p><p>
176 This macro is defined in the file "c++config" in the
177 "libstdc++-v3/include/bits" directory. (Up to GCC 4.1.0, it was
178 changed every night by an automated script. Since GCC 4.1.0, it is
179 the same value as gcc/DATESTAMP.)
180 </p><p>
181 It is versioned as follows:
182 </p><div class="itemizedlist"><ul class="itemizedlist" 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.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.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></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" 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" type="disc"><li class="listitem"><p>GCC 3.0.0: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.1: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.2: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.3: include/g++-v3</p></li><li class="listitem"><p>GCC 3.0.4: include/g++-v3</p></li><li class="listitem"><p>GCC 3.1.0: include/g++-v3</p></li><li class="listitem"><p>GCC 3.1.1: include/c++/3.1.1</p></li><li class="listitem"><p>GCC 3.2.0: include/c++/3.2</p></li><li class="listitem"><p>GCC 3.2.1: include/c++/3.2.1</p></li><li class="listitem"><p>GCC 3.2.2: include/c++/3.2.2</p></li><li class="listitem"><p>GCC 3.2.3: include/c++/3.2.3</p></li><li class="listitem"><p>GCC 3.3.0: include/c++/3.3</p></li><li class="listitem"><p>GCC 3.3.1: include/c++/3.3.1</p></li><li class="listitem"><p>GCC 3.3.2: include/c++/3.3.2</p></li><li class="listitem"><p>GCC 3.3.3: include/c++/3.3.3</p></li><li class="listitem"><p>GCC 3.4.x: include/c++/3.4.x</p></li><li class="listitem"><p>GCC 4.x.y: include/c++/4.x.y</p></li></ul></div><p></p></li></ol></div><p>
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" title="Prerequisites"><div class="titlepage"><div><div><h4 class="title"><a name="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" title="Configuring"><div class="titlepage"><div><div><h4 class="title"><a name="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" title="Checking Active"><div class="titlepage"><div><div><h4 class="title"><a name="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++:
251 </p><pre class="screen">
252 <code class="computeroutput">
253 checking versioning on shared library symbols... gnu
254 </code>
255 </pre><p>
256 or another of the supported styles.
257 If you don't see this line in the configure output, or if this line
258 appears but the last word is 'no', then you are out of luck.
259 </p><p>
260 If the compiler is pre-installed, a quick way to test is to compile
261 the following (or any) simple C++ file and link it to the shared
262 libstdc++ library:
263 </p><pre class="programlisting">
264 #include &lt;iostream&gt;
265
266 int main()
267 { std::cout &lt;&lt; "hello" &lt;&lt; std::endl; return 0; }
268
269 %g++ hello.cc -o hello.out
270
271 %ldd hello.out
272 libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
273 libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
274 libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000)
275 libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
276 /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
277
278 %nm hello.out
279 </pre><p>
280 If you see symbols in the resulting output with "GLIBCXX_3" as part
281 of the name, then the executable is versioned. Here's an example:
282 </p><p>
283 <code class="code">U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code>
284 </p><p>
285 On Solaris 2, you can use <code class="code">pvs -r</code> instead:
286 </p><pre class="programlisting">
287 %g++ hello.cc -o hello.out
288
289 %pvs -r hello.out
290 libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12);
291 libgcc_s.so.1 (GCC_3.0);
292 libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
293 </pre><p>
294 <code class="code">ldd -v</code> works too, but is very verbose.
295 </p></div></div><div class="section" title="Allowed Changes"><div class="titlepage"><div><div><h3 class="title"><a name="abi.changes_allowed"></a>Allowed Changes</h3></div></div></div><p>
296 The following will cause the library minor version number to
297 increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5".
298 </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>
299 Other allowed changes are possible.
300 </p></div><div class="section" title="Prohibited Changes"><div class="titlepage"><div><div><h3 class="title"><a name="abi.changes_no"></a>Prohibited Changes</h3></div></div></div><p>
301 The following non-exhaustive list will cause the library major version
302 number to increase, say from "libstdc++.so.3.0.4" to
303 "libstdc++.so.4.0.0".
304 </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
305 base classes</p></li><li class="listitem"><p>
306 Changing the size, alignment, or layout of types
307 specified in the C++ standard. These may not necessarily be
308 instantiated or otherwise exported in the library binary, and
309 include all the required locale facets, as well as things like
310 std::basic_streambuf, et al.
311 </p></li><li class="listitem"><p> Adding an explicit copy constructor or destructor to a
312 class that would otherwise have implicit versions. This will change
313 the way the compiler deals with this class in by-value return
314 statements or parameters: instead of passing instances of this
315 class in registers, the compiler will be forced to use memory. See the
316 section on <a class="link" href="http://www.codesourcery.com/public/cxx-abi/abi.html#calls" target="_top">Function
317 Calling Conventions and APIs</a>
318 of the C++ ABI documentation for further details.
319 </p></li></ol></div></div><div class="section" title="Implementation"><div class="titlepage"><div><div><h3 class="title"><a name="abi.impl"></a>Implementation</h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p>
320 Separation of interface and implementation
321 </p><p>
322 This is accomplished by two techniques that separate the API from
323 the ABI: forcing undefined references to link against a library
324 binary for definitions.
325 </p><div class="variablelist"><dl><dt><span class="term">Include files have declarations, source files have defines</span></dt><dd><p>
326 For non-templatized types, such as much of <code class="code">class
327 locale</code>, the appropriate standard C++ include, say
328 <code class="code">locale</code>, can contain full declarations, while
329 various source files (say <code class="code"> locale.cc, locale_init.cc,
330 localename.cc</code>) contain definitions.
331 </p></dd><dt><span class="term">Extern template on required types</span></dt><dd><p>
332 For parts of the standard that have an explicit list of
333 required instantiations, the GNU extension syntax <code class="code"> extern
334 template </code> can be used to control where template
335 definitions reside. By marking required instantiations as
336 <code class="code"> extern template </code> in include files, and providing
337 explicit instantiations in the appropriate instantiation files,
338 non-inlined template functions can be versioned. This technique
339 is mostly used on parts of the standard that require <code class="code">
340 char</code> and <code class="code"> wchar_t</code> instantiations, and
341 includes <code class="code"> basic_string</code>, the locale facets, and the
342 types in <code class="code"> iostreams</code>.
343 </p></dd></dl></div><p>
344 In addition, these techniques have the additional benefit that they
345 reduce binary size, which can increase runtime performance.
346 </p></li><li class="listitem"><p>
347 Namespaces linking symbol definitions to export mapfiles
348 </p><p>
349 All symbols in the shared library binary are processed by a
350 linker script at build time that either allows or disallows
351 external linkage. Because of this, some symbols, regardless of
352 normal C/C++ linkage, are not visible. Symbols that are internal
353 have several appealing characteristics: by not exporting the
354 symbols, there are no relocations when the shared library is
355 started and thus this makes for faster runtime loading
356 performance by the underlying dynamic loading mechanism. In
357 addition, they have the possibility of changing without impacting
358 ABI compatibility.
359 </p><p>The following namespaces are transformed by the mapfile:</p><div class="variablelist"><dl><dt><span class="term"><code class="code">namespace std</code></span></dt><dd><p> Defaults to exporting all symbols in label
360 <code class="code">GLIBCXX</code> that do not begin with an underscore, i.e.,
361 <code class="code">__test_func</code> would not be exported by default. Select
362 exceptional symbols are allowed to be visible.</p></dd><dt><span class="term"><code class="code">namespace __gnu_cxx</code></span></dt><dd><p> Defaults to not exporting any symbols in label
363 <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
364 <code class="code">CXXABI</code>, select items are allowed to be visible.</p></dd></dl></div><p>
365 </p></li><li class="listitem"><p>Freezing the API</p><p>Disallowed changes, as above, are not made on a stable release
366 branch. Enforcement tends to be less strict with GNU extensions that
367 standard includes.</p></li></ol></div></div><div class="section" title="Testing"><div class="titlepage"><div><div><h3 class="title"><a name="abi.testing"></a>Testing</h3></div></div></div><div class="section" title="Single ABI Testing"><div class="titlepage"><div><div><h4 class="title"><a name="abi.testing.single"></a>Single ABI Testing</h4></div></div></div><p>
368 Testing for GNU C++ ABI changes is composed of two distinct
369 areas: testing the C++ compiler (g++) for compiler changes, and
370 testing the C++ library (libstdc++) for library changes.
371 </p><p>
372 Testing the C++ compiler ABI can be done various ways.
373 </p><p>
374 One. Intel ABI checker.
375 </p><p>
376 Two.
377 The second is yet unreleased, but has been announced on the gcc
378 mailing list. It is yet unspecified if these tools will be freely
379 available, and able to be included in a GNU project. Please contact
380 Mark Mitchell (mark@codesourcery.com) for more details, and current
381 status.
382 </p><p>
383 Three.
384 Involves using the vlad.consistency test framework. This has also been
385 discussed on the gcc mailing lists.
386 </p><p>
387 Testing the C++ library ABI can also be done various ways.
388 </p><p>
389 One.
390 (Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
391 one with a new compiler and an old library, and the other with an old
392 compiler and a new library, and look for testsuite regressions)
393 </p><p>
394 Details on how to set this kind of test up can be found here:
395 http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
396 </p><p>
397 Two.
398 Use the 'make check-abi' rule in the libstdc++ Makefile.
399 </p><p>
400 This is a proactive check of the library ABI. Currently, exported symbol
401 names that are either weak or defined are checked against a last known
402 good baseline. Currently, this baseline is keyed off of 3.4.0
403 binaries, as this was the last time the .so number was incremented. In
404 addition, all exported names are demangled, and the exported objects
405 are checked to make sure they are the same size as the same object in
406 the baseline.
407
408 Notice that each baseline is relative to a <span class="emphasis"><em>default</em></span>
409 configured library and compiler: in particular, if options such as
410 --enable-clocale, or --with-cpu, in case of multilibs, are used at
411 configure time, the check may fail, either because of substantive
412 differences or because of limitations of the current checking
413 machinery.
414 </p><p>
415 This dataset is insufficient, yet a start. Also needed is a
416 comprehensive check for all user-visible types part of the standard
417 library for sizeof() and alignof() changes.
418 </p><p>
419 Verifying compatible layouts of objects is not even attempted. It
420 should be possible to use sizeof, alignof, and offsetof to compute
421 offsets for each structure and type in the standard library, saving to
422 another datafile. Then, compute this in a similar way for new
423 binaries, and look for differences.
424 </p><p>
425 Another approach might be to use the -fdump-class-hierarchy flag to
426 get information. However, currently this approach gives insufficient
427 data for use in library testing, as class data members, their offsets,
428 and other detailed data is not displayed with this flag.
429 (See PR g++/7470 on how this was used to find bugs.)
430 </p><p>
431 Perhaps there are other C++ ABI checkers. If so, please notify
432 us. We'd like to know about them!
433 </p></div><div class="section" title="Multiple ABI Testing"><div class="titlepage"><div><div><h4 class="title"><a name="abi.testing.multi"></a>Multiple ABI Testing</h4></div></div></div><p>
434 A "C" application, dynamically linked to two shared libraries, liba,
435 libb. The dependent library liba is a C++ shared library compiled with
436 GCC 3.3, and uses io, exceptions, locale, etc. The dependent library
437 libb is a C++ shared library compiled with GCC 3.4, and also uses io,
438 exceptions, locale, etc.
439 </p><p> As above, libone is constructed as follows: </p><pre class="programlisting">
440 %$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc
441
442 %$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
443
444 %ln -s libone.so.1.0.0 libone.so
445
446 %$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc
447
448 %ar cru libone.a a.o
449 </pre><p> And, libtwo is constructed as follows: </p><pre class="programlisting">
450 %$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc
451
452 %$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
453
454 %ln -s libtwo.so.1.0.0 libtwo.so
455
456 %$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc
457
458 %ar cru libtwo.a b.o
459 </pre><p> ...with the resulting libraries looking like </p><pre class="screen">
460 <code class="computeroutput">
461 %ldd libone.so.1.0.0
462 libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40016000)
463 libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400fa000)
464 libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000)
465 libc.so.6 =&gt; /lib/tls/libc.so.6 (0x40125000)
466 /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
467
468 %ldd libtwo.so.1.0.0
469 libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x40027000)
470 libm.so.6 =&gt; /lib/tls/libm.so.6 (0x400e1000)
471 libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000)
472 libc.so.6 =&gt; /lib/tls/libc.so.6 (0x4010c000)
473 /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
474 </code>
475 </pre><p>
476 Then, the "C" compiler is used to compile a source file that uses
477 functions from each library.
478 </p><pre class="programlisting">
479 gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6
480 </pre><p>
481 Which gives the expected:
482 </p><pre class="screen">
483 <code class="computeroutput">
484 %ldd a.out
485 libstdc++.so.5 =&gt; /usr/lib/libstdc++.so.5 (0x00764000)
486 libstdc++.so.6 =&gt; /usr/lib/libstdc++.so.6 (0x40015000)
487 libc.so.6 =&gt; /lib/tls/libc.so.6 (0x0036d000)
488 libm.so.6 =&gt; /lib/tls/libm.so.6 (0x004a8000)
489 libgcc_s.so.1 =&gt; /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000)
490 /lib/ld-linux.so.2 =&gt; /lib/ld-linux.so.2 (0x00355000)
491 </code>
492 </pre><p>
493 This resulting binary, when executed, will be able to safely use
494 code from both liba, and the dependent libstdc++.so.6, and libb,
495 with the dependent libstdc++.so.5.
496 </p></div></div><div class="section" title="Outstanding Issues"><div class="titlepage"><div><div><h3 class="title"><a name="abi.issues"></a>Outstanding Issues</h3></div></div></div><p>
497 Some features in the C++ language make versioning especially
498 difficult. In particular, compiler generated constructs such as
499 implicit instantiations for templates, typeinfo information, and
500 virtual tables all may cause ABI leakage across shared library
501 boundaries. Because of this, mixing C++ ABIs is not recommended at
502 this time.
503 </p><p>
504 For more background on this issue, see these bugzilla entries:
505 </p><p>
506 <a class="link" href="http://gcc.gnu.org/PR24660" target="_top">24660: versioning weak symbols in libstdc++</a>
507 </p><p>
508 <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>
509 </p></div><div class="bibliography" title="Bibliography"><div class="titlepage"><div><div><h3 class="title"><a name="abi.biblio"></a>Bibliography</h3></div></div></div><div class="biblioentry" title="ABIcheck"><a name="biblio.abicheck"></a><p>[biblio.abicheck] <span class="title"><i>
510 <a class="link" href="http://abicheck.sourceforge.net" target="_top">
511 ABIcheck
512 </a>
513 </i>. </span></p></div><div class="biblioentry" title="C++ ABI Summary"><a name="biblio.cxxabi"></a><p>[biblio.cxxabi] <span class="title"><i>
514 <a class="link" href="http://www.codesourcery.com/public/cxx-abi" target="_top">
515 C++ ABI Summary
516 </a>
517 </i>. </span></p></div><div class="biblioentry" title="Intel Compilers for Linux Compatibility with the GNU Compilers"><a name="id684275"></a><p><span class="title"><i>
518 <a class="link" href="http://www.intel.com/cd/software/products/asmo-na/eng/284736.htm" target="_top">
519 Intel Compilers for Linux Compatibility with the GNU Compilers
520 </a>
521 </i>. </span></p></div><div class="biblioentry" title="Linker and Libraries Guide (document 819-0690)"><a name="id684291"></a><p><span class="title"><i>
522 <a class="link" href="http://download.oracle.com/docs/cd/E19963-01/html/819-0690/index.html" target="_top">
523 Linker and Libraries Guide (document 819-0690)
524 </a>
525 </i>. </span></p></div><div class="biblioentry" title="Sun Studio 11: C++ Migration Guide (document 819-3689)"><a name="id684306"></a><p><span class="title"><i>
526 <a class="link" href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html" target="_top">
527 Sun Studio 11: C++ Migration Guide (document 819-3689)
528 </a>
529 </i>. </span></p></div><div class="biblioentry" title="How to Write Shared Libraries"><a name="id684322"></a><p><span class="title"><i>
530 <a class="link" href="http://www.akkadia.org/drepper/dsohowto.pdf" target="_top">
531 How to Write Shared Libraries
532 </a>
533 </i>. </span><span class="author"><span class="firstname">Ulrich</span> <span class="surname">Drepper</span>. </span></p></div><div class="biblioentry" title="C++ ABI for the ARM Architecture"><a name="id684350"></a><p><span class="title"><i>
534 <a class="link" href="http://www.arm.com/miscPDFs/8033.pdf" target="_top">
535 C++ ABI for the ARM Architecture
536 </a>
537 </i>. </span></p></div><div class="biblioentry" title="Dynamic Shared Objects: Survey and Issues"><a name="id684365"></a><p><span class="title"><i>
538 <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html" target="_top">
539 Dynamic Shared Objects: Survey and Issues
540 </a>
541 </i>. </span><span class="subtitle">
542 ISO C++ J16/06-0046
543 . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span></p></div><div class="biblioentry" title="Versioning With Namespaces"><a name="id684393"></a><p><span class="title"><i>
544 <a class="link" href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html" target="_top">
545 Versioning With Namespaces
546 </a>
547 </i>. </span><span class="subtitle">
548 ISO C++ J16/06-0083
549 . </span><span class="author"><span class="firstname">Benjamin</span> <span class="surname">Kosnik</span>. </span></p></div><div class="biblioentry" title="Binary Compatibility of Shared Libraries Implemented in C++ on GNU/Linux Systems"><a name="id684420"></a><p><span class="title"><i>
550 <a class="link" href="http://syrcose.ispras.ru/2009/files/SYRCoSE2009-CfP.pdf" target="_top">
551 Binary Compatibility of Shared Libraries Implemented in C++
552 on GNU/Linux Systems
553 </a>
554 </i>. </span><span class="subtitle">
555 SYRCoSE 2009
556 . </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>