abi.xml revision 1.5
1<section xmlns="http://docbook.org/ns/docbook" version="5.0" 2 xml:id="appendix.porting.abi" xreflabel="abi"> 3<?dbhtml filename="abi.html"?> 4 5<info><title>ABI Policy and Guidelines</title> 6 <keywordset> 7 <keyword>C++</keyword> 8 <keyword>ABI</keyword> 9 <keyword>version</keyword> 10 <keyword>dynamic</keyword> 11 <keyword>shared</keyword> 12 <keyword>compatibility</keyword> 13 </keywordset> 14</info> 15 16 17 18<para> 19</para> 20 21<section xml:id="abi.cxx_interface"><info><title>The C++ Interface</title></info> 22 23 24<para> 25 C++ applications often depend on specific language support 26 routines, say for throwing exceptions, or catching exceptions, and 27 perhaps also depend on features in the C++ Standard Library. 28</para> 29 30<para> 31 The C++ Standard Library has many include files, types defined in 32 those include files, specific named functions, and other 33 behavior. The text of these behaviors, as written in source include 34 files, is called the Application Programing Interface, or API. 35</para> 36 37<para> 38 Furthermore, C++ source that is compiled into object files is 39 transformed by the compiler: it arranges objects with specific 40 alignment and in a particular layout, mangling names according to a 41 well-defined algorithm, has specific arrangements for the support of 42 virtual functions, etc. These details are defined as the compiler 43 Application Binary Interface, or ABI. The GNU C++ compiler uses an 44 industry-standard C++ ABI starting with version 3. Details can be 45 found in the <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://mentorembedded.github.com/cxx-abi/abi.html">ABI 46 specification</link>. 47</para> 48 49<para> 50 The GNU C++ compiler, g++, has a compiler command line option to 51 switch between various different C++ ABIs. This explicit version 52 switch is the flag <code>-fabi-version</code>. In addition, some 53 g++ command line options may change the ABI as a side-effect of 54 use. Such flags include <code>-fpack-struct</code> and 55 <code>-fno-exceptions</code>, but include others: see the complete 56 list in the GCC manual under the heading <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/onlinedocs/gcc/Code-Gen-Options.html#Code%20Gen%20Options">Options 57 for Code Generation Conventions</link>. 58</para> 59 60<para> 61 The configure options used when building a specific libstdc++ 62 version may also impact the resulting library ABI. The available 63 configure options, and their impact on the library ABI, are 64 documented 65<link linkend="manual.intro.setup.configure">here</link>. 66</para> 67 68<para> Putting all of these ideas together results in the C++ Standard 69Library ABI, which is the compilation of a given library API by a 70given compiler ABI. In a nutshell: 71</para> 72 73<para> 74 <quote> 75 library API + compiler ABI = library ABI 76 </quote> 77</para> 78 79<para> 80 The library ABI is mostly of interest for end-users who have 81 unresolved symbols and are linking dynamically to the C++ Standard 82 library, and who thus must be careful to compile their application 83 with a compiler that is compatible with the available C++ Standard 84 library binary. In this case, compatible is defined with the equation 85 above: given an application compiled with a given compiler ABI and 86 library API, it will work correctly with a Standard C++ Library 87 created with the same constraints. 88</para> 89 90<para> 91 To use a specific version of the C++ ABI, one must use a 92 corresponding GNU C++ toolchain (i.e., g++ and libstdc++) that 93 implements the C++ ABI in question. 94</para> 95 96</section> 97 98<section xml:id="abi.versioning"><info><title>Versioning</title></info> 99 100 101<para> The C++ interface has evolved throughout the history of the GNU 102C++ toolchain. With each release, various details have been changed so 103as to give distinct versions to the C++ interface. 104</para> 105 106 <section xml:id="abi.versioning.goals"><info><title>Goals</title></info> 107 108 109<para>Extending existing, stable ABIs. Versioning gives subsequent 110releases of library binaries the ability to add new symbols and add 111functionality, all the while retaining compatibility with the previous 112releases in the series. Thus, program binaries linked with the initial 113release of a library binary will still run correctly if the library 114binary is replaced by carefully-managed subsequent library 115binaries. This is called forward compatibility. 116</para> 117<para> 118The reverse (backwards compatibility) is not true. It is not possible 119to take program binaries linked with the latest version of a library 120binary in a release series (with additional symbols added), substitute 121in the initial release of the library binary, and remain link 122compatible. 123</para> 124 125<para>Allows multiple, incompatible ABIs to coexist at the same time. 126</para> 127 </section> 128 129 <section xml:id="abi.versioning.history"><info><title>History</title></info> 130 131 132<para> 133 How can this complexity be managed? What does C++ versioning mean? 134 Because library and compiler changes often make binaries compiled 135 with one version of the GNU tools incompatible with binaries 136 compiled with other (either newer or older) versions of the same GNU 137 tools, specific techniques are used to make managing this complexity 138 easier. 139</para> 140 141<para> 142 The following techniques are used: 143</para> 144 145 <orderedlist> 146 147 <listitem><para>Release versioning on the libgcc_s.so binary. </para> 148 149 <para>This is implemented via file names and the ELF 150 <constant>DT_SONAME</constant> mechanism (at least on ELF 151 systems). It is versioned as follows: 152 </para> 153 154 <itemizedlist> 155 <listitem><para>GCC 3.x: libgcc_s.so.1</para></listitem> 156 <listitem><para>GCC 4.x: libgcc_s.so.1</para></listitem> 157 </itemizedlist> 158 159 <para>For m68k-linux the versions differ as follows: </para> 160 161 <itemizedlist> 162 <listitem><para>GCC 3.4, GCC 4.x: libgcc_s.so.1 163 when configuring <code>--with-sjlj-exceptions</code>, or 164 libgcc_s.so.2 </para> </listitem> 165 </itemizedlist> 166 167 <para>For hppa-linux the versions differ as follows: </para> 168 169 <itemizedlist> 170 <listitem><para>GCC 3.4, GCC 4.[0-1]: either libgcc_s.so.1 171 when configuring <code>--with-sjlj-exceptions</code>, or 172 libgcc_s.so.2 </para> </listitem> 173 <listitem><para>GCC 4.[2-7]: either libgcc_s.so.3 when configuring 174 <code>--with-sjlj-exceptions</code>) or libgcc_s.so.4 175 </para> </listitem> 176 </itemizedlist> 177 178 </listitem> 179 180 <listitem><para>Symbol versioning on the libgcc_s.so binary.</para> 181 182 <para>It is versioned with the following labels and version 183 definitions, where the version definition is the maximum for a 184 particular release. Labels are cumulative. If a particular release 185 is not listed, it has the same version labels as the preceding 186 release.</para> 187 188 <para>This corresponds to the mapfile: gcc/libgcc-std.ver</para> 189 <itemizedlist> 190 <listitem><para>GCC 3.0.0: GCC_3.0</para></listitem> 191 <listitem><para>GCC 3.3.0: GCC_3.3</para></listitem> 192 <listitem><para>GCC 3.3.1: GCC_3.3.1</para></listitem> 193 <listitem><para>GCC 3.3.2: GCC_3.3.2</para></listitem> 194 <listitem><para>GCC 3.3.4: GCC_3.3.4</para></listitem> 195 <listitem><para>GCC 3.4.0: GCC_3.4</para></listitem> 196 <listitem><para>GCC 3.4.2: GCC_3.4.2</para></listitem> 197 <listitem><para>GCC 3.4.4: GCC_3.4.4</para></listitem> 198 <listitem><para>GCC 4.0.0: GCC_4.0.0</para></listitem> 199 <listitem><para>GCC 4.1.0: GCC_4.1.0</para></listitem> 200 <listitem><para>GCC 4.2.0: GCC_4.2.0</para></listitem> 201 <listitem><para>GCC 4.3.0: GCC_4.3.0</para></listitem> 202 <listitem><para>GCC 4.4.0: GCC_4.4.0</para></listitem> 203 <listitem><para>GCC 4.5.0: GCC_4.5.0</para></listitem> 204 <listitem><para>GCC 4.6.0: GCC_4.6.0</para></listitem> 205 <listitem><para>GCC 4.7.0: GCC_4.7.0</para></listitem> 206 <listitem><para>GCC 4.8.0: GCC_4.8.0</para></listitem> 207 </itemizedlist> 208 </listitem> 209 210 <listitem> 211 <para> 212 Release versioning on the libstdc++.so binary, implemented in 213 the same way as the libgcc_s.so binary above. Listed is the 214 filename: <constant>DT_SONAME</constant> can be deduced from 215 the filename by removing the last two period-delimited numbers. For 216 example, filename <filename>libstdc++.so.5.0.4</filename> 217 corresponds to a <constant>DT_SONAME</constant> of 218 <constant>libstdc++.so.5</constant>. Binaries with equivalent 219 <constant>DT_SONAME</constant>s are forward-compatibile: in 220 the table below, releases incompatible with the previous 221 one are explicitly noted. 222 If a particular release is not listed, its libstdc++.so binary 223 has the same filename and <constant>DT_SONAME</constant> as the 224 preceding release. 225 </para> 226 227 <para>It is versioned as follows: 228 </para> 229 <itemizedlist> 230 <listitem><para>GCC 3.0.0: libstdc++.so.3.0.0</para></listitem> 231 <listitem><para>GCC 3.0.1: libstdc++.so.3.0.1</para></listitem> 232 <listitem><para>GCC 3.0.2: libstdc++.so.3.0.2</para></listitem> 233 <listitem><para>GCC 3.0.3: libstdc++.so.3.0.2 (See Note 1)</para></listitem> 234 <listitem><para>GCC 3.0.4: libstdc++.so.3.0.4</para></listitem> 235 <listitem><para>GCC 3.1.0: libstdc++.so.4.0.0 <emphasis>(Incompatible with previous)</emphasis></para></listitem> 236 <listitem><para>GCC 3.1.1: libstdc++.so.4.0.1</para></listitem> 237 <listitem><para>GCC 3.2.0: libstdc++.so.5.0.0 <emphasis>(Incompatible with previous)</emphasis></para></listitem> 238 <listitem><para>GCC 3.2.1: libstdc++.so.5.0.1</para></listitem> 239 <listitem><para>GCC 3.2.2: libstdc++.so.5.0.2</para></listitem> 240 <listitem><para>GCC 3.2.3: libstdc++.so.5.0.3 (See Note 2)</para></listitem> 241 <listitem><para>GCC 3.3.0: libstdc++.so.5.0.4</para></listitem> 242 <listitem><para>GCC 3.3.1: libstdc++.so.5.0.5</para></listitem> 243 <listitem><para>GCC 3.4.0: libstdc++.so.6.0.0 <emphasis>(Incompatible with previous)</emphasis></para></listitem> 244 <listitem><para>GCC 3.4.1: libstdc++.so.6.0.1</para></listitem> 245 <listitem><para>GCC 3.4.2: libstdc++.so.6.0.2</para></listitem> 246 <listitem><para>GCC 3.4.3: libstdc++.so.6.0.3</para></listitem> 247 <listitem><para>GCC 4.0.0: libstdc++.so.6.0.4</para></listitem> 248 <listitem><para>GCC 4.0.1: libstdc++.so.6.0.5</para></listitem> 249 <listitem><para>GCC 4.0.2: libstdc++.so.6.0.6</para></listitem> 250 <listitem><para>GCC 4.0.3: libstdc++.so.6.0.7</para></listitem> 251 <listitem><para>GCC 4.1.0: libstdc++.so.6.0.7</para></listitem> 252 <listitem><para>GCC 4.1.1: libstdc++.so.6.0.8</para></listitem> 253 <listitem><para>GCC 4.2.0: libstdc++.so.6.0.9</para></listitem> 254 <listitem><para>GCC 4.2.1: libstdc++.so.6.0.9 (See Note 3)</para></listitem> 255 <listitem><para>GCC 4.2.2: libstdc++.so.6.0.9</para></listitem> 256 <listitem><para>GCC 4.3.0: libstdc++.so.6.0.10</para></listitem> 257 <listitem><para>GCC 4.4.0: libstdc++.so.6.0.11</para></listitem> 258 <listitem><para>GCC 4.4.1: libstdc++.so.6.0.12</para></listitem> 259 <listitem><para>GCC 4.4.2: libstdc++.so.6.0.13</para></listitem> 260 <listitem><para>GCC 4.5.0: libstdc++.so.6.0.14</para></listitem> 261 <listitem><para>GCC 4.6.0: libstdc++.so.6.0.15</para></listitem> 262 <listitem><para>GCC 4.6.1: libstdc++.so.6.0.16</para></listitem> 263 <listitem><para>GCC 4.7.0: libstdc++.so.6.0.17</para></listitem> 264 <listitem><para>GCC 4.8.0: libstdc++.so.6.0.18</para></listitem> 265 <listitem><para>GCC 4.8.3: libstdc++.so.6.0.19</para></listitem> 266 <listitem><para>GCC 4.9.0: libstdc++.so.6.0.20</para></listitem> 267 <listitem><para>GCC 5.1.0: libstdc++.so.6.0.21</para></listitem> 268 </itemizedlist> 269 <para> 270 Note 1: Error should be libstdc++.so.3.0.3. 271 </para> 272 <para> 273 Note 2: Not strictly required. 274 </para> 275 <para> 276 Note 3: This release (but not previous or subsequent) has one 277 known incompatibility, see <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33678">33678</link> 278 in the GCC bug database. 279 </para> 280 </listitem> 281 282 <listitem><para>Symbol versioning on the libstdc++.so binary.</para> 283 284 <para>mapfile: libstdc++-v3/config/abi/pre/gnu.ver</para> 285 <para>It is versioned with the following labels and version 286 definitions, where the version definition is the maximum for a 287 particular release. Note, only symbols which are newly introduced 288 will use the maximum version definition. Thus, for release series 289 with the same label, but incremented version definitions, the later 290 release has both versions. (An example of this would be the 291 GCC 3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and 292 GLIBCPP_3.2 for symbols that were introduced in the GCC 3.2.0 293 release.) If a particular release is not listed, it has the same 294 version labels as the preceding release. 295 </para> 296 <itemizedlist> 297 <listitem><para>GCC 3.0.0: (Error, not versioned)</para></listitem> 298 <listitem><para>GCC 3.0.1: (Error, not versioned)</para></listitem> 299 <listitem><para>GCC 3.0.2: (Error, not versioned)</para></listitem> 300 <listitem><para>GCC 3.0.3: (Error, not versioned)</para></listitem> 301 <listitem><para>GCC 3.0.4: (Error, not versioned)</para></listitem> 302 <listitem><para>GCC 3.1.0: GLIBCPP_3.1, CXXABI_1</para></listitem> 303 <listitem><para>GCC 3.1.1: GLIBCPP_3.1, CXXABI_1</para></listitem> 304 <listitem><para>GCC 3.2.0: GLIBCPP_3.2, CXXABI_1.2</para></listitem> 305 <listitem><para>GCC 3.2.1: GLIBCPP_3.2.1, CXXABI_1.2</para></listitem> 306 <listitem><para>GCC 3.2.2: GLIBCPP_3.2.2, CXXABI_1.2</para></listitem> 307 <listitem><para>GCC 3.2.3: GLIBCPP_3.2.2, CXXABI_1.2</para></listitem> 308 <listitem><para>GCC 3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1</para></listitem> 309 <listitem><para>GCC 3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> 310 <listitem><para>GCC 3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> 311 <listitem><para>GCC 3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1</para></listitem> 312 <listitem><para>GCC 3.4.0: GLIBCXX_3.4, CXXABI_1.3</para></listitem> 313 <listitem><para>GCC 3.4.1: GLIBCXX_3.4.1, CXXABI_1.3</para></listitem> 314 <listitem><para>GCC 3.4.2: GLIBCXX_3.4.2</para></listitem> 315 <listitem><para>GCC 3.4.3: GLIBCXX_3.4.3</para></listitem> 316 <listitem><para>GCC 4.0.0: GLIBCXX_3.4.4, CXXABI_1.3.1</para></listitem> 317 <listitem><para>GCC 4.0.1: GLIBCXX_3.4.5</para></listitem> 318 <listitem><para>GCC 4.0.2: GLIBCXX_3.4.6</para></listitem> 319 <listitem><para>GCC 4.0.3: GLIBCXX_3.4.7</para></listitem> 320 <listitem><para>GCC 4.1.1: GLIBCXX_3.4.8</para></listitem> 321 <listitem><para>GCC 4.2.0: GLIBCXX_3.4.9</para></listitem> 322 <listitem><para>GCC 4.3.0: GLIBCXX_3.4.10, CXXABI_1.3.2</para></listitem> 323 <listitem><para>GCC 4.4.0: GLIBCXX_3.4.11, CXXABI_1.3.3</para></listitem> 324 <listitem><para>GCC 4.4.1: GLIBCXX_3.4.12, CXXABI_1.3.3</para></listitem> 325 <listitem><para>GCC 4.4.2: GLIBCXX_3.4.13, CXXABI_1.3.3</para></listitem> 326 <listitem><para>GCC 4.5.0: GLIBCXX_3.4.14, CXXABI_1.3.4</para></listitem> 327 <listitem><para>GCC 4.6.0: GLIBCXX_3.4.15, CXXABI_1.3.5</para></listitem> 328 <listitem><para>GCC 4.6.1: GLIBCXX_3.4.16, CXXABI_1.3.5</para></listitem> 329 <listitem><para>GCC 4.7.0: GLIBCXX_3.4.17, CXXABI_1.3.6</para></listitem> 330 <listitem><para>GCC 4.8.0: GLIBCXX_3.4.18, CXXABI_1.3.7</para></listitem> 331 <listitem><para>GCC 4.8.3: GLIBCXX_3.4.19, CXXABI_1.3.7</para></listitem> 332 <listitem><para>GCC 4.9.0: GLIBCXX_3.4.20, CXXABI_1.3.8</para></listitem> 333 <listitem><para>GCC 5.1.0: GLIBCXX_3.4.21, CXXABI_1.3.9</para></listitem> 334 </itemizedlist> 335 </listitem> 336 337 <listitem> 338 <para>Incremental bumping of a compiler pre-defined macro, 339 __GXX_ABI_VERSION. This macro is defined as the version of the 340 compiler v3 ABI, with g++ 3.0 being version 100. This macro will 341 be automatically defined whenever g++ is used (the curious can 342 test this by invoking g++ with the '-v' flag.) 343 </para> 344 345 <para> 346 This macro was defined in the file "lang-specs.h" in the gcc/cp directory. 347 Later versions defined it in "c-common.c" in the gcc directory, and from 348 G++ 3.4 it is defined in c-cppbuiltin.c and its value determined by the 349 '-fabi-version' command line option. 350 </para> 351 352 <para> 353 It is versioned as follows, where 'n' is given by '-fabi-version=n': 354 </para> 355 <itemizedlist> 356 <listitem><para>GCC 3.0: 100</para></listitem> 357 <listitem><para>GCC 3.1: 100 (Error, should be 101)</para></listitem> 358 <listitem><para>GCC 3.2: 102</para></listitem> 359 <listitem><para>GCC 3.3: 102</para></listitem> 360 <listitem><para>GCC 3.4, GCC 4.x: 102 (when n=1)</para></listitem> 361 <listitem><para>GCC 3.4, GCC 4.x: 1000 + n (when n>1) </para></listitem> 362 <listitem><para>GCC 3.4, GCC 4.x: 999999 (when n=0)</para></listitem> 363 </itemizedlist> 364 <para/> 365 </listitem> 366 367 <listitem> 368 <para>Changes to the default compiler option for 369 <code>-fabi-version</code>. 370 </para> 371 <para> 372 It is versioned as follows: 373 </para> 374 <itemizedlist> 375 <listitem><para>GCC 3.0: (Error, not versioned) </para></listitem> 376 <listitem><para>GCC 3.1: (Error, not versioned) </para></listitem> 377 <listitem><para>GCC 3.2: <code>-fabi-version=1</code></para></listitem> 378 <listitem><para>GCC 3.3: <code>-fabi-version=1</code></para></listitem> 379 <listitem><para>GCC 3.4, GCC 4.x: <code>-fabi-version=2</code> <emphasis>(Incompatible with previous)</emphasis></para></listitem> 380 </itemizedlist> 381 <para/> 382 </listitem> 383 384 <listitem> 385 <para>Incremental bumping of a library pre-defined macro. For releases 386 before 3.4.0, the macro is __GLIBCPP__. For later releases, it's 387 __GLIBCXX__. (The libstdc++ project generously changed from CPP to 388 CXX throughout its source to allow the "C" pre-processor the CPP 389 macro namespace.) These macros are defined as the date the library 390 was released, in compressed ISO date format, as an unsigned long. 391 </para> 392 393 <para> 394 This macro is defined in the file "c++config" in the 395 "libstdc++-v3/include/bits" directory. (Up to GCC 4.1.0, it was 396 changed every night by an automated script. Since GCC 4.1.0, it is 397 the same value as gcc/DATESTAMP.) 398 </para> 399 <para> 400 It is versioned as follows: 401 </para> 402 <itemizedlist> 403 <listitem><para>GCC 3.0.0: 20010615</para></listitem> 404 <listitem><para>GCC 3.0.1: 20010819</para></listitem> 405 <listitem><para>GCC 3.0.2: 20011023</para></listitem> 406 <listitem><para>GCC 3.0.3: 20011220</para></listitem> 407 <listitem><para>GCC 3.0.4: 20020220</para></listitem> 408 <listitem><para>GCC 3.1.0: 20020514</para></listitem> 409 <listitem><para>GCC 3.1.1: 20020725</para></listitem> 410 <listitem><para>GCC 3.2.0: 20020814</para></listitem> 411 <listitem><para>GCC 3.2.1: 20021119</para></listitem> 412 <listitem><para>GCC 3.2.2: 20030205</para></listitem> 413 <listitem><para>GCC 3.2.3: 20030422</para></listitem> 414 <listitem><para>GCC 3.3.0: 20030513</para></listitem> 415 <listitem><para>GCC 3.3.1: 20030804</para></listitem> 416 <listitem><para>GCC 3.3.2: 20031016</para></listitem> 417 <listitem><para>GCC 3.3.3: 20040214</para></listitem> 418 <listitem><para>GCC 3.4.0: 20040419</para></listitem> 419 <listitem><para>GCC 3.4.1: 20040701</para></listitem> 420 <listitem><para>GCC 3.4.2: 20040906</para></listitem> 421 <listitem><para>GCC 3.4.3: 20041105</para></listitem> 422 <listitem><para>GCC 3.4.4: 20050519</para></listitem> 423 <listitem><para>GCC 3.4.5: 20051201</para></listitem> 424 <listitem><para>GCC 3.4.6: 20060306</para></listitem> 425 <listitem><para>GCC 4.0.0: 20050421</para></listitem> 426 <listitem><para>GCC 4.0.1: 20050707</para></listitem> 427 <listitem><para>GCC 4.0.2: 20050921</para></listitem> 428 <listitem><para>GCC 4.0.3: 20060309</para></listitem> 429 <listitem><para>GCC 4.1.0: 20060228</para></listitem> 430 <listitem><para>GCC 4.1.1: 20060524</para></listitem> 431 <listitem><para>GCC 4.1.2: 20070214</para></listitem> 432 <listitem><para>GCC 4.2.0: 20070514</para></listitem> 433 <listitem><para>GCC 4.2.1: 20070719</para></listitem> 434 <listitem><para>GCC 4.2.2: 20071007</para></listitem> 435 <listitem><para>GCC 4.2.3: 20080201</para></listitem> 436 <listitem><para>GCC 4.2.4: 20080519</para></listitem> 437 <listitem><para>GCC 4.3.0: 20080306</para></listitem> 438 <listitem><para>GCC 4.3.1: 20080606</para></listitem> 439 <listitem><para>GCC 4.3.2: 20080827</para></listitem> 440 <listitem><para>GCC 4.3.3: 20090124</para></listitem> 441 <listitem><para>GCC 4.3.4: 20090804</para></listitem> 442 <listitem><para>GCC 4.3.5: 20100522</para></listitem> 443 <listitem><para>GCC 4.3.6: 20110627</para></listitem> 444 <listitem><para>GCC 4.4.0: 20090421</para></listitem> 445 <listitem><para>GCC 4.4.1: 20090722</para></listitem> 446 <listitem><para>GCC 4.4.2: 20091015</para></listitem> 447 <listitem><para>GCC 4.4.3: 20100121</para></listitem> 448 <listitem><para>GCC 4.4.4: 20100429</para></listitem> 449 <listitem><para>GCC 4.4.5: 20101001</para></listitem> 450 <listitem><para>GCC 4.4.6: 20110416</para></listitem> 451 <listitem><para>GCC 4.4.7: 20120313</para></listitem> 452 <listitem><para>GCC 4.5.0: 20100414</para></listitem> 453 <listitem><para>GCC 4.5.1: 20100731</para></listitem> 454 <listitem><para>GCC 4.5.2: 20101216</para></listitem> 455 <listitem><para>GCC 4.5.3: 20110428</para></listitem> 456 <listitem><para>GCC 4.5.4: 20120702</para></listitem> 457 <listitem><para>GCC 4.6.0: 20110325</para></listitem> 458 <listitem><para>GCC 4.6.1: 20110627</para></listitem> 459 <listitem><para>GCC 4.6.2: 20111026</para></listitem> 460 <listitem><para>GCC 4.6.3: 20120301</para></listitem> 461 <listitem><para>GCC 4.7.0: 20120322</para></listitem> 462 <listitem><para>GCC 4.7.1: 20120614</para></listitem> 463 <listitem><para>GCC 4.7.2: 20120920</para></listitem> 464 </itemizedlist> 465 <para/> 466 </listitem> 467 468 <listitem> 469 <para> 470 Incremental bumping of a library pre-defined macro, 471 _GLIBCPP_VERSION. This macro is defined as the released version of 472 the library, as a string literal. This is only implemented in 473 GCC 3.1.0 releases and higher, and is deprecated in 3.4 (where it 474 is called _GLIBCXX_VERSION). 475 </para> 476 477 <para> 478 This macro is defined in the file "c++config" in the 479 "libstdc++-v3/include/bits" directory and is generated 480 automatically by autoconf as part of the configure-time generation 481 of config.h. 482 </para> 483 484 <para> 485 It is versioned as follows: 486 </para> 487 <itemizedlist> 488 <listitem><para>GCC 3.0.0: "3.0.0"</para></listitem> 489 <listitem><para>GCC 3.0.1: "3.0.0" (Error, should be "3.0.1")</para></listitem> 490 <listitem><para>GCC 3.0.2: "3.0.0" (Error, should be "3.0.2")</para></listitem> 491 <listitem><para>GCC 3.0.3: "3.0.0" (Error, should be "3.0.3")</para></listitem> 492 <listitem><para>GCC 3.0.4: "3.0.0" (Error, should be "3.0.4")</para></listitem> 493 <listitem><para>GCC 3.1.0: "3.1.0"</para></listitem> 494 <listitem><para>GCC 3.1.1: "3.1.1"</para></listitem> 495 <listitem><para>GCC 3.2.0: "3.2"</para></listitem> 496 <listitem><para>GCC 3.2.1: "3.2.1"</para></listitem> 497 <listitem><para>GCC 3.2.2: "3.2.2"</para></listitem> 498 <listitem><para>GCC 3.2.3: "3.2.3"</para></listitem> 499 <listitem><para>GCC 3.3.0: "3.3"</para></listitem> 500 <listitem><para>GCC 3.3.1: "3.3.1"</para></listitem> 501 <listitem><para>GCC 3.3.2: "3.3.2"</para></listitem> 502 <listitem><para>GCC 3.3.3: "3.3.3"</para></listitem> 503 <listitem><para>GCC 3.4: "version-unused"</para></listitem> 504 <listitem><para>GCC 4.x: "version-unused"</para></listitem> 505 </itemizedlist> 506 <para/> 507 </listitem> 508 509 <listitem> 510 <para> 511 Matching each specific C++ compiler release to a specific set of 512 C++ include files. This is only implemented in GCC 3.1.1 releases 513 and higher. 514 </para> 515 <para> 516 All C++ includes are installed in 517 <filename class="directory">include/c++</filename>, then nest in a 518 directory hierarchy corresponding to the C++ compiler's released 519 version. This version corresponds to the variable "gcc_version" in 520 "libstdc++-v3/acinclude.m4," and more details can be found in that 521 file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before GCC 3.4.0). 522 </para> 523 <para> 524 C++ includes are versioned as follows: 525 </para> 526 <itemizedlist> 527 <listitem><para>GCC 3.0.0: include/g++-v3</para></listitem> 528 <listitem><para>GCC 3.0.1: include/g++-v3</para></listitem> 529 <listitem><para>GCC 3.0.2: include/g++-v3</para></listitem> 530 <listitem><para>GCC 3.0.3: include/g++-v3</para></listitem> 531 <listitem><para>GCC 3.0.4: include/g++-v3</para></listitem> 532 <listitem><para>GCC 3.1.0: include/g++-v3</para></listitem> 533 <listitem><para>GCC 3.1.1: include/c++/3.1.1</para></listitem> 534 <listitem><para>GCC 3.2.0: include/c++/3.2</para></listitem> 535 <listitem><para>GCC 3.2.1: include/c++/3.2.1</para></listitem> 536 <listitem><para>GCC 3.2.2: include/c++/3.2.2</para></listitem> 537 <listitem><para>GCC 3.2.3: include/c++/3.2.3</para></listitem> 538 <listitem><para>GCC 3.3.0: include/c++/3.3</para></listitem> 539 <listitem><para>GCC 3.3.1: include/c++/3.3.1</para></listitem> 540 <listitem><para>GCC 3.3.2: include/c++/3.3.2</para></listitem> 541 <listitem><para>GCC 3.3.3: include/c++/3.3.3</para></listitem> 542 <listitem><para>GCC 3.4.x: include/c++/3.4.x</para></listitem> 543 <listitem><para>GCC 4.x.y: include/c++/4.x.y</para></listitem> 544 <listitem><para>GCC 5.x.0: include/c++/5.x.0</para></listitem> 545 </itemizedlist> 546 <para/> 547 </listitem> 548 </orderedlist> 549 550<para> 551 Taken together, these techniques can accurately specify interface 552 and implementation changes in the GNU C++ tools themselves. Used 553 properly, they allow both the GNU C++ tools implementation, and 554 programs using them, an evolving yet controlled development that 555 maintains backward compatibility. 556</para> 557 558 559 </section> 560 561 <section xml:id="abi.versioning.prereq"><info><title>Prerequisites</title></info> 562 563 <para> 564 Minimum environment that supports a versioned ABI: A supported 565 dynamic linker, a GNU linker of sufficient vintage to understand 566 demangled C++ name globbing (ld) or the Sun linker, a shared 567 executable compiled 568 with g++, and shared libraries (libgcc_s, libstdc++) compiled by 569 a compiler (g++) with a compatible ABI. Phew. 570 </para> 571 572 <para> 573 On top of all that, an additional constraint: libstdc++ did not 574 attempt to version symbols (or age gracefully, really) until 575 version 3.1.0. 576 </para> 577 578 <para> 579 Most modern GNU/Linux and BSD versions, particularly ones using 580 GCC 3.1 and later, will meet the 581 requirements above, as does Solaris 2.5 and up. 582 </para> 583 </section> 584 585 <section xml:id="abi.versioning.config"><info><title>Configuring</title></info> 586 587 588 <para> 589 It turns out that most of the configure options that change 590 default behavior will impact the mangled names of exported 591 symbols, and thus impact versioning and compatibility. 592 </para> 593 594 <para> 595 For more information on configure options, including ABI 596 impacts, see: 597 <link linkend="manual.intro.setup.configure">here</link> 598 </para> 599 600 <para> 601 There is one flag that explicitly deals with symbol versioning: 602 --enable-symvers. 603 </para> 604 605 <para> 606 In particular, libstdc++-v3/acinclude.m4 has a macro called 607 GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument 608 passed in via --enable-symvers=foo). At that point, the macro 609 attempts to make sure that all the requirement for symbol 610 versioning are in place. For more information, please consult 611 acinclude.m4. 612 </para> 613 </section> 614 615 <section xml:id="abi.versioning.active"><info><title>Checking Active</title></info> 616 617 618 <para> 619 When the GNU C++ library is being built with symbol versioning 620 on, you should see the following at configure time for 621 libstdc++: 622 </para> 623 624<screen> 625<computeroutput> 626 checking versioning on shared library symbols... gnu 627</computeroutput> 628</screen> 629 630<para> 631 or another of the supported styles. 632 If you don't see this line in the configure output, or if this line 633 appears but the last word is 'no', then you are out of luck. 634</para> 635 636<para> 637 If the compiler is pre-installed, a quick way to test is to compile 638 the following (or any) simple C++ file and link it to the shared 639 libstdc++ library: 640</para> 641 642<programlisting> 643#include <iostream> 644 645int main() 646{ std::cout << "hello" << std::endl; return 0; } 647 648%g++ hello.cc -o hello.out 649 650%ldd hello.out 651 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) 652 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 653 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000) 654 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 655 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 656 657%nm hello.out 658</programlisting> 659 660<para> 661If you see symbols in the resulting output with "GLIBCXX_3" as part 662of the name, then the executable is versioned. Here's an example: 663</para> 664 665<para> 666 <code>U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code> 667</para> 668 669<para> 670On Solaris 2, you can use <code>pvs -r</code> instead: 671</para> 672 673<programlisting> 674%g++ hello.cc -o hello.out 675 676%pvs -r hello.out 677 libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12); 678 libgcc_s.so.1 (GCC_3.0); 679 libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3); 680</programlisting> 681 682<para> 683<code>ldd -v</code> works too, but is very verbose. 684</para> 685 686 </section> 687</section> 688 689<section xml:id="abi.changes_allowed"><info><title>Allowed Changes</title></info> 690 691 692<para> 693The following will cause the library minor version number to 694increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". 695</para> 696<orderedlist> 697 <listitem><para>Adding an exported global or static data member</para></listitem> 698 <listitem><para>Adding an exported function, static or non-virtual member function</para></listitem> 699 <listitem><para>Adding an exported symbol or symbols by additional instantiations</para></listitem> 700</orderedlist> 701<para> 702Other allowed changes are possible. 703</para> 704 705</section> 706 707<section xml:id="abi.changes_no"><info><title>Prohibited Changes</title></info> 708 709 710<para> 711The following non-exhaustive list will cause the library major version 712number to increase, say from "libstdc++.so.3.0.4" to 713"libstdc++.so.4.0.0". 714</para> 715 716<orderedlist> 717 <listitem><para>Changes in the gcc/g++ compiler ABI</para></listitem> 718<listitem><para>Changing size of an exported symbol</para></listitem> 719<listitem><para>Changing alignment of an exported symbol</para></listitem> 720<listitem><para>Changing the layout of an exported symbol</para></listitem> 721<listitem><para>Changing mangling on an exported symbol</para></listitem> 722<listitem><para>Deleting an exported symbol</para></listitem> 723<listitem><para>Changing the inheritance properties of a type by adding or removing 724 base classes</para></listitem> 725<listitem><para> 726 Changing the size, alignment, or layout of types 727 specified in the C++ standard. These may not necessarily be 728 instantiated or otherwise exported in the library binary, and 729 include all the required locale facets, as well as things like 730 std::basic_streambuf, et al. 731</para></listitem> 732 733<listitem><para> Adding an explicit copy constructor or destructor to a 734class that would otherwise have implicit versions. This will change 735the way the compiler deals with this class in by-value return 736statements or parameters: instead of passing instances of this 737class in registers, the compiler will be forced to use memory. See the 738section on <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://mentorembedded.github.com/cxx-abi/abi.html#calls">Function 739Calling Conventions and APIs</link> 740 of the C++ ABI documentation for further details. 741</para></listitem> 742 743</orderedlist> 744 745</section> 746 747 748 749<section xml:id="abi.impl"><info><title>Implementation</title></info> 750 751 752<orderedlist> 753 <listitem> 754 <para> 755 Separation of interface and implementation 756 </para> 757 <para> 758 This is accomplished by two techniques that separate the API from 759 the ABI: forcing undefined references to link against a library 760 binary for definitions. 761 </para> 762 763<variablelist> 764 <varlistentry> 765 <term>Include files have declarations, source files have defines</term> 766 767 <listitem> 768 <para> 769 For non-templatized types, such as much of <code>class 770 locale</code>, the appropriate standard C++ include, say 771 <code>locale</code>, can contain full declarations, while 772 various source files (say <code> locale.cc, locale_init.cc, 773 localename.cc</code>) contain definitions. 774 </para> 775 </listitem> 776 </varlistentry> 777 778 <varlistentry> 779 <term>Extern template on required types</term> 780 781 <listitem> 782 <para> 783 For parts of the standard that have an explicit list of 784 required instantiations, the GNU extension syntax <code> extern 785 template </code> can be used to control where template 786 definitions reside. By marking required instantiations as 787 <code> extern template </code> in include files, and providing 788 explicit instantiations in the appropriate instantiation files, 789 non-inlined template functions can be versioned. This technique 790 is mostly used on parts of the standard that require <code> 791 char</code> and <code> wchar_t</code> instantiations, and 792 includes <code> basic_string</code>, the locale facets, and the 793 types in <code> iostreams</code>. 794 </para> 795 </listitem> 796 </varlistentry> 797 798 </variablelist> 799 800 <para> 801 In addition, these techniques have the additional benefit that they 802 reduce binary size, which can increase runtime performance. 803 </para> 804 </listitem> 805 806 <listitem> 807 <para> 808 Namespaces linking symbol definitions to export mapfiles 809 </para> 810 <para> 811 All symbols in the shared library binary are processed by a 812 linker script at build time that either allows or disallows 813 external linkage. Because of this, some symbols, regardless of 814 normal C/C++ linkage, are not visible. Symbols that are internal 815 have several appealing characteristics: by not exporting the 816 symbols, there are no relocations when the shared library is 817 started and thus this makes for faster runtime loading 818 performance by the underlying dynamic loading mechanism. In 819 addition, they have the possibility of changing without impacting 820 ABI compatibility. 821 </para> 822 823<para>The following namespaces are transformed by the mapfile:</para> 824 825<variablelist> 826 827 <varlistentry> 828<term><code>namespace std</code></term> 829<listitem><para> Defaults to exporting all symbols in label 830<code>GLIBCXX</code> that do not begin with an underscore, i.e., 831<code>__test_func</code> would not be exported by default. Select 832exceptional symbols are allowed to be visible.</para></listitem> 833 </varlistentry> 834 835 <varlistentry> 836<term><code>namespace __gnu_cxx</code></term> 837<listitem><para> Defaults to not exporting any symbols in label 838<code>GLIBCXX</code>, select items are allowed to be visible.</para></listitem> 839 </varlistentry> 840 841 <varlistentry> 842<term><code>namespace __gnu_internal</code></term> 843<listitem><para> Defaults to not exported, no items are allowed to be visible.</para></listitem> 844 </varlistentry> 845 846 <varlistentry> 847<term><code>namespace __cxxabiv1</code>, aliased to <code> namespace abi</code></term> 848<listitem><para> Defaults to not exporting any symbols in label 849<code>CXXABI</code>, select items are allowed to be visible.</para></listitem> 850 </varlistentry> 851 852</variablelist> 853<para> 854</para> 855</listitem> 856 857 <listitem><para>Freezing the API</para> 858 <para>Disallowed changes, as above, are not made on a stable release 859branch. Enforcement tends to be less strict with GNU extensions that 860standard includes.</para> 861</listitem> 862</orderedlist> 863 864</section> 865 866<section xml:id="abi.testing"><info><title>Testing</title></info> 867 868 869 <section xml:id="abi.testing.single"><info><title>Single ABI Testing</title></info> 870 871 872 <para> 873 Testing for GNU C++ ABI changes is composed of two distinct 874 areas: testing the C++ compiler (g++) for compiler changes, and 875 testing the C++ library (libstdc++) for library changes. 876 </para> 877 878 <para> 879 Testing the C++ compiler ABI can be done various ways. 880 </para> 881 882 <para> 883 One. Intel ABI checker. 884 </para> 885 886<para> 887Two. 888The second is yet unreleased, but has been announced on the gcc 889mailing list. It is yet unspecified if these tools will be freely 890available, and able to be included in a GNU project. Please contact 891Mark Mitchell (mark@codesourcery.com) for more details, and current 892status. 893</para> 894 895<para> 896Three. 897Involves using the vlad.consistency test framework. This has also been 898discussed on the gcc mailing lists. 899</para> 900 901<para> 902Testing the C++ library ABI can also be done various ways. 903</para> 904 905<para> 906One. 907(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 908one with a new compiler and an old library, and the other with an old 909compiler and a new library, and look for testsuite regressions) 910</para> 911 912<para> 913Details on how to set this kind of test up can be found here: 914http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html 915</para> 916 917<para> 918Two. 919Use the 'make check-abi' rule in the libstdc++ Makefile. 920</para> 921 922<para> 923This is a proactive check of the library ABI. Currently, exported symbol 924names that are either weak or defined are checked against a last known 925good baseline. Currently, this baseline is keyed off of 3.4.0 926binaries, as this was the last time the .so number was incremented. In 927addition, all exported names are demangled, and the exported objects 928are checked to make sure they are the same size as the same object in 929the baseline. 930 931Notice that each baseline is relative to a <emphasis>default</emphasis> 932configured library and compiler: in particular, if options such as 933--enable-clocale, or --with-cpu, in case of multilibs, are used at 934configure time, the check may fail, either because of substantive 935differences or because of limitations of the current checking 936machinery. 937</para> 938 939<para> 940This dataset is insufficient, yet a start. Also needed is a 941comprehensive check for all user-visible types part of the standard 942library for sizeof() and alignof() changes. 943</para> 944 945<para> 946Verifying compatible layouts of objects is not even attempted. It 947should be possible to use sizeof, alignof, and offsetof to compute 948offsets for each structure and type in the standard library, saving to 949another datafile. Then, compute this in a similar way for new 950binaries, and look for differences. 951</para> 952 953<para> 954Another approach might be to use the -fdump-class-hierarchy flag to 955get information. However, currently this approach gives insufficient 956data for use in library testing, as class data members, their offsets, 957and other detailed data is not displayed with this flag. 958(See PR g++/7470 on how this was used to find bugs.) 959</para> 960 961<para> 962Perhaps there are other C++ ABI checkers. If so, please notify 963us. We'd like to know about them! 964</para> 965 966 </section> 967 <section xml:id="abi.testing.multi"><info><title>Multiple ABI Testing</title></info> 968 969<para> 970A "C" application, dynamically linked to two shared libraries, liba, 971libb. The dependent library liba is a C++ shared library compiled with 972GCC 3.3, and uses io, exceptions, locale, etc. The dependent library 973libb is a C++ shared library compiled with GCC 3.4, and also uses io, 974exceptions, locale, etc. 975</para> 976 977<para> As above, libone is constructed as follows: </para> 978<programlisting> 979%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc 980 981%$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 982 983%ln -s libone.so.1.0.0 libone.so 984 985%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc 986 987%ar cru libone.a a.o 988</programlisting> 989 990<para> And, libtwo is constructed as follows: </para> 991 992<programlisting> 993%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc 994 995%$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 996 997%ln -s libtwo.so.1.0.0 libtwo.so 998 999%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc 1000 1001%ar cru libtwo.a b.o 1002</programlisting> 1003 1004<para> ...with the resulting libraries looking like </para> 1005 1006<screen> 1007<computeroutput> 1008%ldd libone.so.1.0.0 1009 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000) 1010 libm.so.6 => /lib/tls/libm.so.6 (0x400fa000) 1011 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000) 1012 libc.so.6 => /lib/tls/libc.so.6 (0x40125000) 1013 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1014 1015%ldd libtwo.so.1.0.0 1016 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000) 1017 libm.so.6 => /lib/tls/libm.so.6 (0x400e1000) 1018 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000) 1019 libc.so.6 => /lib/tls/libc.so.6 (0x4010c000) 1020 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1021</computeroutput> 1022</screen> 1023 1024<para> 1025 Then, the "C" compiler is used to compile a source file that uses 1026 functions from each library. 1027</para> 1028<programlisting> 1029gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 1030</programlisting> 1031 1032<para> 1033 Which gives the expected: 1034</para> 1035 1036<screen> 1037<computeroutput> 1038%ldd a.out 1039 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) 1040 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000) 1041 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 1042 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 1043 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000) 1044 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1045</computeroutput> 1046</screen> 1047 1048<para> 1049 This resulting binary, when executed, will be able to safely use 1050 code from both liba, and the dependent libstdc++.so.6, and libb, 1051 with the dependent libstdc++.so.5. 1052</para> 1053 </section> 1054</section> 1055 1056<section xml:id="abi.issues"><info><title>Outstanding Issues</title></info> 1057 1058 1059<para> 1060 Some features in the C++ language make versioning especially 1061 difficult. In particular, compiler generated constructs such as 1062 implicit instantiations for templates, typeinfo information, and 1063 virtual tables all may cause ABI leakage across shared library 1064 boundaries. Because of this, mixing C++ ABIs is not recommended at 1065 this time. 1066</para> 1067 1068<para> 1069 For more background on this issue, see these bugzilla entries: 1070</para> 1071 1072<para> 1073<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/PR24660">24660: versioning weak symbols in libstdc++</link> 1074</para> 1075 1076<para> 1077<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/PR19664">19664: libstdc++ headers should have pop/push of the visibility around the declarations</link> 1078</para> 1079 1080</section> 1081 1082<bibliography xml:id="abi.biblio"><info><title>Bibliography</title></info> 1083 1084 <biblioentry xml:id="biblio.abicheck"> 1085 <title> 1086 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1087 xlink:href="http://abicheck.sourceforge.net"> 1088 ABIcheck 1089 </link> 1090 </title> 1091 </biblioentry> 1092 1093 <biblioentry xml:id="biblio.cxxabi"> 1094 <title> 1095 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1096 xlink:href="http://www.codesourcery.com/cxx-abi/"> 1097 C++ ABI Summary 1098 </link> 1099 </title> 1100 </biblioentry> 1101 1102 1103 <biblioentry> 1104 <title> 1105 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1106 xlink:href="https://software.intel.com/en-us/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers"> 1107 Intel Compilers for Linux: Compatibility with GNU Compilers 1108 </link> 1109 </title> 1110 </biblioentry> 1111 1112 <biblioentry> 1113 <title> 1114 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1115 xlink:href="http://docs.oracle.com/cd/E23824_01/html/819-0690/index.html"> 1116 Linker and Libraries Guide (document 819-0690) 1117 </link> 1118 </title> 1119 </biblioentry> 1120 1121 1122 <biblioentry> 1123 <title> 1124 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1125 xlink:href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html"> 1126 Sun Studio 11: C++ Migration Guide (document 819-3689) 1127 </link> 1128 </title> 1129 </biblioentry> 1130 1131 <biblioentry> 1132 <title> 1133 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1134 xlink:href="http://www.akkadia.org/drepper/dsohowto.pdf"> 1135 How to Write Shared Libraries 1136 </link> 1137 </title> 1138 1139 <author> 1140 <personname> 1141 <firstname>Ulrich</firstname><surname>Drepper</surname> 1142 </personname> 1143 </author> 1144 </biblioentry> 1145 1146 <biblioentry> 1147 <title> 1148 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1149 xlink:href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0036b/index.html"> 1150 C++ ABI for the ARM Architecture 1151 </link> 1152 </title> 1153 </biblioentry> 1154 1155 <biblioentry> 1156 <title> 1157 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1158 xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html"> 1159 Dynamic Shared Objects: Survey and Issues 1160 </link> 1161 </title> 1162 1163 <subtitle> 1164 ISO C++ J16/06-0046 1165 </subtitle> 1166 <author><personname><firstname>Benjamin</firstname><surname>Kosnik</surname></personname></author> 1167 </biblioentry> 1168 1169 <biblioentry> 1170 <title> 1171 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1172 xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html"> 1173 Versioning With Namespaces 1174 </link> 1175 </title> 1176 <subtitle> 1177 ISO C++ J16/06-0083 1178 </subtitle> 1179 <author><personname><firstname>Benjamin</firstname><surname>Kosnik</surname></personname></author> 1180 </biblioentry> 1181 1182 <biblioentry> 1183 <title> 1184 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1185 xlink:href="http://syrcose.ispras.ru/2009/files/02_paper.pdf"> 1186 Binary Compatibility of Shared Libraries Implemented in C++ 1187 on GNU/Linux Systems 1188 </link> 1189 </title> 1190 1191 <subtitle> 1192 SYRCoSE 2009 1193 </subtitle> 1194 <author><personname><firstname>Pavel</firstname><surname>Shved</surname></personname></author> 1195 <author><personname><firstname>Denis</firstname><surname>Silakov</surname></personname></author> 1196 </biblioentry> 1197</bibliography> 1198 1199</section> 1200