abi.xml revision 1.1.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.io/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 set 397 during configuration to the same value as 398 <filename>gcc/DATESTAMP</filename>, so for an official release its value 399 is the same as the date of the release, which is given in the <link 400 xmlns:xlink="http://www.w3.org/1999/xlink" 401 xlink:href="https://gcc.gnu.org/develop.html#timeline">GCC Release 402 Timeline</link>. 403 </para> 404 405 <para> 406 This macro is not useful for determining whether a particular feature is 407 supported by the version of libstdc++ you are using. The date of a release 408 might be after a feature was added to the development trunk, but the 409 release could be from an older branch. For example, in the 5.4.0 release 410 the macro has the value 20160603 which is greater than the 20160427 value 411 of the macro in the 6.1.0 release, but there are features supported in the 412 6.1.0 release that are not supported in 5.4.0 release. 413 You also can't test for the exact values listed below to try and 414 identify a release, because a snapshot taken from the gcc-5-branch on 415 2016-04-27 would have the same value for the macro as the 6.1.0 release 416 despite being a different version. 417 Many GNU/Linux distributions build their GCC packages from snapshots, so 418 the macro can have dates that doesn't correspond to official releases. 419 </para> 420 421 <para> 422 It is versioned as follows: 423 </para> 424 <itemizedlist> 425 <listitem><para>GCC 3.0.0: 20010615</para></listitem> 426 <listitem><para>GCC 3.0.1: 20010819</para></listitem> 427 <listitem><para>GCC 3.0.2: 20011023</para></listitem> 428 <listitem><para>GCC 3.0.3: 20011220</para></listitem> 429 <listitem><para>GCC 3.0.4: 20020220</para></listitem> 430 <listitem><para>GCC 3.1.0: 20020514</para></listitem> 431 <listitem><para>GCC 3.1.1: 20020725</para></listitem> 432 <listitem><para>GCC 3.2.0: 20020814</para></listitem> 433 <listitem><para>GCC 3.2.1: 20021119</para></listitem> 434 <listitem><para>GCC 3.2.2: 20030205</para></listitem> 435 <listitem><para>GCC 3.2.3: 20030422</para></listitem> 436 <listitem><para>GCC 3.3.0: 20030513</para></listitem> 437 <listitem><para>GCC 3.3.1: 20030804</para></listitem> 438 <listitem><para>GCC 3.3.2: 20031016</para></listitem> 439 <listitem><para>GCC 3.3.3: 20040214</para></listitem> 440 <listitem><para>GCC 3.4.0: 20040419</para></listitem> 441 <listitem><para>GCC 3.4.1: 20040701</para></listitem> 442 <listitem><para>GCC 3.4.2: 20040906</para></listitem> 443 <listitem><para>GCC 3.4.3: 20041105</para></listitem> 444 <listitem><para>GCC 3.4.4: 20050519</para></listitem> 445 <listitem><para>GCC 3.4.5: 20051201</para></listitem> 446 <listitem><para>GCC 3.4.6: 20060306</para></listitem> 447 <listitem><para>GCC 4.0.0: 20050421</para></listitem> 448 <listitem><para>GCC 4.0.1: 20050707</para></listitem> 449 <listitem><para>GCC 4.0.2: 20050921</para></listitem> 450 <listitem><para>GCC 4.0.3: 20060309</para></listitem> 451 <listitem><para> 452 GCC 4.1.0 and later: the GCC release date, as shown in the 453 <link xmlns:xlink="http://www.w3.org/1999/xlink" 454 xlink:href="https://gcc.gnu.org/develop.html#timeline">GCC 455 Release Timeline</link> 456 </para></listitem> 457 </itemizedlist> 458 <para/> 459 </listitem> 460 461 <listitem> 462 <para> 463 Incremental bumping of a library pre-defined macro, 464 _GLIBCPP_VERSION. This macro is defined as the released version of 465 the library, as a string literal. This is only implemented in 466 GCC 3.1.0 releases and higher, and is deprecated in 3.4 (where it 467 is called _GLIBCXX_VERSION). 468 </para> 469 470 <para> 471 This macro is defined in the file "c++config" in the 472 "libstdc++-v3/include/bits" directory and is generated 473 automatically by autoconf as part of the configure-time generation 474 of config.h. 475 </para> 476 477 <para> 478 It is versioned as follows: 479 </para> 480 <itemizedlist> 481 <listitem><para>GCC 3.0.0: "3.0.0"</para></listitem> 482 <listitem><para>GCC 3.0.1: "3.0.0" (Error, should be "3.0.1")</para></listitem> 483 <listitem><para>GCC 3.0.2: "3.0.0" (Error, should be "3.0.2")</para></listitem> 484 <listitem><para>GCC 3.0.3: "3.0.0" (Error, should be "3.0.3")</para></listitem> 485 <listitem><para>GCC 3.0.4: "3.0.0" (Error, should be "3.0.4")</para></listitem> 486 <listitem><para>GCC 3.1.0: "3.1.0"</para></listitem> 487 <listitem><para>GCC 3.1.1: "3.1.1"</para></listitem> 488 <listitem><para>GCC 3.2.0: "3.2"</para></listitem> 489 <listitem><para>GCC 3.2.1: "3.2.1"</para></listitem> 490 <listitem><para>GCC 3.2.2: "3.2.2"</para></listitem> 491 <listitem><para>GCC 3.2.3: "3.2.3"</para></listitem> 492 <listitem><para>GCC 3.3.0: "3.3"</para></listitem> 493 <listitem><para>GCC 3.3.1: "3.3.1"</para></listitem> 494 <listitem><para>GCC 3.3.2: "3.3.2"</para></listitem> 495 <listitem><para>GCC 3.3.3: "3.3.3"</para></listitem> 496 <listitem><para>GCC 3.4: "version-unused"</para></listitem> 497 <listitem><para>GCC 4.x: "version-unused"</para></listitem> 498 </itemizedlist> 499 <para/> 500 </listitem> 501 502 <listitem> 503 <para> 504 Matching each specific C++ compiler release to a specific set of 505 C++ include files. This is only implemented in GCC 3.1.1 releases 506 and higher. 507 </para> 508 <para> 509 All C++ includes are installed in 510 <filename class="directory">include/c++</filename>, then nest in a 511 directory hierarchy corresponding to the C++ compiler's released 512 version. This version corresponds to the variable "gcc_version" in 513 "libstdc++-v3/acinclude.m4," and more details can be found in that 514 file's macro GLIBCXX_CONFIGURE (GLIBCPP_CONFIGURE before GCC 3.4.0). 515 </para> 516 <para> 517 C++ includes are versioned as follows: 518 </para> 519 <itemizedlist> 520 <listitem><para>GCC 3.0.0: include/g++-v3</para></listitem> 521 <listitem><para>GCC 3.0.1: include/g++-v3</para></listitem> 522 <listitem><para>GCC 3.0.2: include/g++-v3</para></listitem> 523 <listitem><para>GCC 3.0.3: include/g++-v3</para></listitem> 524 <listitem><para>GCC 3.0.4: include/g++-v3</para></listitem> 525 <listitem><para>GCC 3.1.0: include/g++-v3</para></listitem> 526 <listitem><para>GCC 3.1.1: include/c++/3.1.1</para></listitem> 527 <listitem><para>GCC 3.2.0: include/c++/3.2</para></listitem> 528 <listitem><para>GCC 3.2.1: include/c++/3.2.1</para></listitem> 529 <listitem><para>GCC 3.2.2: include/c++/3.2.2</para></listitem> 530 <listitem><para>GCC 3.2.3: include/c++/3.2.3</para></listitem> 531 <listitem><para>GCC 3.3.0: include/c++/3.3</para></listitem> 532 <listitem><para>GCC 3.3.1: include/c++/3.3.1</para></listitem> 533 <listitem><para>GCC 3.3.2: include/c++/3.3.2</para></listitem> 534 <listitem><para>GCC 3.3.3: include/c++/3.3.3</para></listitem> 535 <listitem><para>GCC 3.4.x: include/c++/3.4.x</para></listitem> 536 <listitem><para>GCC 4.x.y: include/c++/4.x.y</para></listitem> 537 <listitem><para>GCC 5.x.0: include/c++/5.x.0</para></listitem> 538 </itemizedlist> 539 <para/> 540 </listitem> 541 </orderedlist> 542 543<para> 544 Taken together, these techniques can accurately specify interface 545 and implementation changes in the GNU C++ tools themselves. Used 546 properly, they allow both the GNU C++ tools implementation, and 547 programs using them, an evolving yet controlled development that 548 maintains backward compatibility. 549</para> 550 551 552 </section> 553 554 <section xml:id="abi.versioning.prereq"><info><title>Prerequisites</title></info> 555 556 <para> 557 Minimum environment that supports a versioned ABI: A supported 558 dynamic linker, a GNU linker of sufficient vintage to understand 559 demangled C++ name globbing (ld) or the Sun linker, a shared 560 executable compiled 561 with g++, and shared libraries (libgcc_s, libstdc++) compiled by 562 a compiler (g++) with a compatible ABI. Phew. 563 </para> 564 565 <para> 566 On top of all that, an additional constraint: libstdc++ did not 567 attempt to version symbols (or age gracefully, really) until 568 version 3.1.0. 569 </para> 570 571 <para> 572 Most modern GNU/Linux and BSD versions, particularly ones using 573 GCC 3.1 and later, will meet the 574 requirements above, as does Solaris 2.5 and up. 575 </para> 576 </section> 577 578 <section xml:id="abi.versioning.config"><info><title>Configuring</title></info> 579 580 581 <para> 582 It turns out that most of the configure options that change 583 default behavior will impact the mangled names of exported 584 symbols, and thus impact versioning and compatibility. 585 </para> 586 587 <para> 588 For more information on configure options, including ABI 589 impacts, see: 590 <link linkend="manual.intro.setup.configure">here</link> 591 </para> 592 593 <para> 594 There is one flag that explicitly deals with symbol versioning: 595 --enable-symvers. 596 </para> 597 598 <para> 599 In particular, libstdc++-v3/acinclude.m4 has a macro called 600 GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument 601 passed in via --enable-symvers=foo). At that point, the macro 602 attempts to make sure that all the requirement for symbol 603 versioning are in place. For more information, please consult 604 acinclude.m4. 605 </para> 606 </section> 607 608 <section xml:id="abi.versioning.active"><info><title>Checking Active</title></info> 609 610 611 <para> 612 When the GNU C++ library is being built with symbol versioning 613 on, you should see the following at configure time for 614 libstdc++ (showing either 'gnu' or another of the supported styles): 615 </para> 616 617<screen> 618<computeroutput> 619 checking versioning on shared library symbols... gnu 620</computeroutput> 621</screen> 622 623<para> 624 If you don't see this line in the configure output, or if this line 625 appears but the last word is 'no', then you are out of luck. 626</para> 627 628<para> 629 If the compiler is pre-installed, a quick way to test is to compile 630 the following (or any) simple C++ file and link it to the shared 631 libstdc++ library: 632</para> 633 634<programlisting> 635#include <iostream> 636 637int main() 638{ std::cout << "hello" << std::endl; return 0; } 639 640%g++ hello.cc -o hello.out 641 642%ldd hello.out 643 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) 644 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 645 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40016000) 646 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 647 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 648 649%nm hello.out 650</programlisting> 651 652<para> 653If you see symbols in the resulting output with "GLIBCXX_3" as part 654of the name, then the executable is versioned. Here's an example: 655</para> 656 657<para> 658 <code>U _ZNSt8ios_base4InitC1Ev@@GLIBCXX_3.4</code> 659</para> 660 661<para> 662On Solaris 2, you can use <code>pvs -r</code> instead: 663</para> 664 665<programlisting> 666%g++ hello.cc -o hello.out 667 668%pvs -r hello.out 669 libstdc++.so.6 (GLIBCXX_3.4, GLIBCXX_3.4.12); 670 libgcc_s.so.1 (GCC_3.0); 671 libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3); 672</programlisting> 673 674<para> 675<code>ldd -v</code> works too, but is very verbose. 676</para> 677 678 </section> 679</section> 680 681<section xml:id="abi.changes_allowed"><info><title>Allowed Changes</title></info> 682 683 684<para> 685The following will cause the library minor version number to 686increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.3.0.5". 687</para> 688<orderedlist> 689 <listitem><para>Adding an exported global or static data member</para></listitem> 690 <listitem><para>Adding an exported function, static or non-virtual member function</para></listitem> 691 <listitem><para>Adding an exported symbol or symbols by additional instantiations</para></listitem> 692</orderedlist> 693<para> 694Other allowed changes are possible. 695</para> 696 697</section> 698 699<section xml:id="abi.changes_no"><info><title>Prohibited Changes</title></info> 700 701 702<para> 703The following non-exhaustive list will cause the library major version 704number to increase, say from "libstdc++.so.3.0.4" to 705"libstdc++.so.4.0.0". 706</para> 707 708<orderedlist> 709 <listitem><para>Changes in the gcc/g++ compiler ABI</para></listitem> 710<listitem><para>Changing size of an exported symbol</para></listitem> 711<listitem><para>Changing alignment of an exported symbol</para></listitem> 712<listitem><para>Changing the layout of an exported symbol</para></listitem> 713<listitem><para>Changing mangling on an exported symbol</para></listitem> 714<listitem><para>Deleting an exported symbol</para></listitem> 715<listitem><para>Changing the inheritance properties of a type by adding or removing 716 base classes</para></listitem> 717<listitem><para> 718 Changing the size, alignment, or layout of types 719 specified in the C++ standard. These may not necessarily be 720 instantiated or otherwise exported in the library binary, and 721 include all the required locale facets, as well as things like 722 std::basic_streambuf, et al. 723</para></listitem> 724 725<listitem><para> Adding an explicit copy constructor or destructor to a 726class that would otherwise have implicit versions. This will change 727the way the compiler deals with this class in by-value return 728statements or parameters: instead of passing instances of this 729class in registers, the compiler will be forced to use memory. See the 730section on <link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://mentorembedded.github.io/cxx-abi/abi.html#calls">Function 731Calling Conventions and APIs</link> 732 of the C++ ABI documentation for further details. 733</para></listitem> 734 735</orderedlist> 736 737</section> 738 739 740 741<section xml:id="abi.impl"><info><title>Implementation</title></info> 742 743 744<orderedlist> 745 <listitem> 746 <para> 747 Separation of interface and implementation 748 </para> 749 <para> 750 This is accomplished by two techniques that separate the API from 751 the ABI: forcing undefined references to link against a library 752 binary for definitions. 753 </para> 754 755<variablelist> 756 <varlistentry> 757 <term>Include files have declarations, source files have defines</term> 758 759 <listitem> 760 <para> 761 For non-templatized types, such as much of <code>class 762 locale</code>, the appropriate standard C++ include, say 763 <code>locale</code>, can contain full declarations, while 764 various source files (say <code> locale.cc, locale_init.cc, 765 localename.cc</code>) contain definitions. 766 </para> 767 </listitem> 768 </varlistentry> 769 770 <varlistentry> 771 <term>Extern template on required types</term> 772 773 <listitem> 774 <para> 775 For parts of the standard that have an explicit list of 776 required instantiations, the GNU extension syntax <code> extern 777 template </code> can be used to control where template 778 definitions reside. By marking required instantiations as 779 <code> extern template </code> in include files, and providing 780 explicit instantiations in the appropriate instantiation files, 781 non-inlined template functions can be versioned. This technique 782 is mostly used on parts of the standard that require <code> 783 char</code> and <code> wchar_t</code> instantiations, and 784 includes <code> basic_string</code>, the locale facets, and the 785 types in <code> iostreams</code>. 786 </para> 787 </listitem> 788 </varlistentry> 789 790 </variablelist> 791 792 <para> 793 In addition, these techniques have the additional benefit that they 794 reduce binary size, which can increase runtime performance. 795 </para> 796 </listitem> 797 798 <listitem> 799 <para> 800 Namespaces linking symbol definitions to export mapfiles 801 </para> 802 <para> 803 All symbols in the shared library binary are processed by a 804 linker script at build time that either allows or disallows 805 external linkage. Because of this, some symbols, regardless of 806 normal C/C++ linkage, are not visible. Symbols that are internal 807 have several appealing characteristics: by not exporting the 808 symbols, there are no relocations when the shared library is 809 started and thus this makes for faster runtime loading 810 performance by the underlying dynamic loading mechanism. In 811 addition, they have the possibility of changing without impacting 812 ABI compatibility. 813 </para> 814 815<para>The following namespaces are transformed by the mapfile:</para> 816 817<variablelist> 818 819 <varlistentry> 820<term><code>namespace std</code></term> 821<listitem><para> Defaults to exporting all symbols in label 822<code>GLIBCXX</code> that do not begin with an underscore, i.e., 823<code>__test_func</code> would not be exported by default. Select 824exceptional symbols are allowed to be visible.</para></listitem> 825 </varlistentry> 826 827 <varlistentry> 828<term><code>namespace __gnu_cxx</code></term> 829<listitem><para> Defaults to not exporting any symbols in label 830<code>GLIBCXX</code>, select items are allowed to be visible.</para></listitem> 831 </varlistentry> 832 833 <varlistentry> 834<term><code>namespace __gnu_internal</code></term> 835<listitem><para> Defaults to not exported, no items are allowed to be visible.</para></listitem> 836 </varlistentry> 837 838 <varlistentry> 839<term><code>namespace __cxxabiv1</code>, aliased to <code> namespace abi</code></term> 840<listitem><para> Defaults to not exporting any symbols in label 841<code>CXXABI</code>, select items are allowed to be visible.</para></listitem> 842 </varlistentry> 843 844</variablelist> 845<para> 846</para> 847</listitem> 848 849 <listitem><para>Freezing the API</para> 850 <para>Disallowed changes, as above, are not made on a stable release 851branch. Enforcement tends to be less strict with GNU extensions that 852standard includes.</para> 853</listitem> 854</orderedlist> 855 856</section> 857 858<section xml:id="abi.testing"><info><title>Testing</title></info> 859 860 861 <section xml:id="abi.testing.single"><info><title>Single ABI Testing</title></info> 862 863 864 <para> 865 Testing for GNU C++ ABI changes is composed of two distinct 866 areas: testing the C++ compiler (g++) for compiler changes, and 867 testing the C++ library (libstdc++) for library changes. 868 </para> 869 870 <para> 871 Testing the C++ compiler ABI can be done various ways. 872 </para> 873 874 <para> 875 One. Intel ABI checker. 876 </para> 877 878<para> 879Two. 880The second is yet unreleased, but has been announced on the gcc 881mailing list. It is yet unspecified if these tools will be freely 882available, and able to be included in a GNU project. Please contact 883Mark Mitchell (mark@codesourcery.com) for more details, and current 884status. 885</para> 886 887<para> 888Three. 889Involves using the vlad.consistency test framework. This has also been 890discussed on the gcc mailing lists. 891</para> 892 893<para> 894Testing the C++ library ABI can also be done various ways. 895</para> 896 897<para> 898One. 899(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways, 900one with a new compiler and an old library, and the other with an old 901compiler and a new library, and look for testsuite regressions) 902</para> 903 904<para> 905Details on how to set this kind of test up can be found here: 906http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html 907</para> 908 909<para> 910Two. 911Use the 'make check-abi' rule in the libstdc++ Makefile. 912</para> 913 914<para> 915This is a proactive check of the library ABI. Currently, exported symbol 916names that are either weak or defined are checked against a last known 917good baseline. Currently, this baseline is keyed off of 3.4.0 918binaries, as this was the last time the .so number was incremented. In 919addition, all exported names are demangled, and the exported objects 920are checked to make sure they are the same size as the same object in 921the baseline. 922 923Notice that each baseline is relative to a <emphasis>default</emphasis> 924configured library and compiler: in particular, if options such as 925--enable-clocale, or --with-cpu, in case of multilibs, are used at 926configure time, the check may fail, either because of substantive 927differences or because of limitations of the current checking 928machinery. 929</para> 930 931<para> 932This dataset is insufficient, yet a start. Also needed is a 933comprehensive check for all user-visible types part of the standard 934library for sizeof() and alignof() changes. 935</para> 936 937<para> 938Verifying compatible layouts of objects is not even attempted. It 939should be possible to use sizeof, alignof, and offsetof to compute 940offsets for each structure and type in the standard library, saving to 941another datafile. Then, compute this in a similar way for new 942binaries, and look for differences. 943</para> 944 945<para> 946Another approach might be to use the -fdump-class-hierarchy flag to 947get information. However, currently this approach gives insufficient 948data for use in library testing, as class data members, their offsets, 949and other detailed data is not displayed with this flag. 950(See PR g++/7470 on how this was used to find bugs.) 951</para> 952 953<para> 954Perhaps there are other C++ ABI checkers. If so, please notify 955us. We'd like to know about them! 956</para> 957 958 </section> 959 <section xml:id="abi.testing.multi"><info><title>Multiple ABI Testing</title></info> 960 961<para> 962A "C" application, dynamically linked to two shared libraries, liba, 963libb. The dependent library liba is a C++ shared library compiled with 964GCC 3.3, and uses io, exceptions, locale, etc. The dependent library 965libb is a C++ shared library compiled with GCC 3.4, and also uses io, 966exceptions, locale, etc. 967</para> 968 969<para> As above, libone is constructed as follows: </para> 970<programlisting> 971%$bld/H-x86-gcc-3.4.0/bin/g++ -fPIC -DPIC -c a.cc 972 973%$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 974 975%ln -s libone.so.1.0.0 libone.so 976 977%$bld/H-x86-gcc-3.4.0/bin/g++ -c a.cc 978 979%ar cru libone.a a.o 980</programlisting> 981 982<para> And, libtwo is constructed as follows: </para> 983 984<programlisting> 985%$bld/H-x86-gcc-3.3.3/bin/g++ -fPIC -DPIC -c b.cc 986 987%$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 988 989%ln -s libtwo.so.1.0.0 libtwo.so 990 991%$bld/H-x86-gcc-3.3.3/bin/g++ -c b.cc 992 993%ar cru libtwo.a b.o 994</programlisting> 995 996<para> ...with the resulting libraries looking like </para> 997 998<screen> 999<computeroutput> 1000%ldd libone.so.1.0.0 1001 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40016000) 1002 libm.so.6 => /lib/tls/libm.so.6 (0x400fa000) 1003 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x4011c000) 1004 libc.so.6 => /lib/tls/libc.so.6 (0x40125000) 1005 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1006 1007%ldd libtwo.so.1.0.0 1008 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x40027000) 1009 libm.so.6 => /lib/tls/libm.so.6 (0x400e1000) 1010 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x40103000) 1011 libc.so.6 => /lib/tls/libc.so.6 (0x4010c000) 1012 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1013</computeroutput> 1014</screen> 1015 1016<para> 1017 Then, the "C" compiler is used to compile a source file that uses 1018 functions from each library. 1019</para> 1020<programlisting> 1021gcc test.c -g -O2 -L. -lone -ltwo /usr/lib/libstdc++.so.5 /usr/lib/libstdc++.so.6 1022</programlisting> 1023 1024<para> 1025 Which gives the expected: 1026</para> 1027 1028<screen> 1029<computeroutput> 1030%ldd a.out 1031 libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x00764000) 1032 libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x40015000) 1033 libc.so.6 => /lib/tls/libc.so.6 (0x0036d000) 1034 libm.so.6 => /lib/tls/libm.so.6 (0x004a8000) 1035 libgcc_s.so.1 => /mnt/hd/bld/gcc/gcc/libgcc_s.so.1 (0x400e5000) 1036 /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x00355000) 1037</computeroutput> 1038</screen> 1039 1040<para> 1041 This resulting binary, when executed, will be able to safely use 1042 code from both liba, and the dependent libstdc++.so.6, and libb, 1043 with the dependent libstdc++.so.5. 1044</para> 1045 </section> 1046</section> 1047 1048<section xml:id="abi.issues"><info><title>Outstanding Issues</title></info> 1049 1050 1051<para> 1052 Some features in the C++ language make versioning especially 1053 difficult. In particular, compiler generated constructs such as 1054 implicit instantiations for templates, typeinfo information, and 1055 virtual tables all may cause ABI leakage across shared library 1056 boundaries. Because of this, mixing C++ ABIs is not recommended at 1057 this time. 1058</para> 1059 1060<para> 1061 For more background on this issue, see these bugzilla entries: 1062</para> 1063 1064<para> 1065<link xmlns:xlink="http://www.w3.org/1999/xlink" xlink:href="http://gcc.gnu.org/PR24660">24660: versioning weak symbols in libstdc++</link> 1066</para> 1067 1068<para> 1069<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> 1070</para> 1071 1072</section> 1073 1074<bibliography xml:id="abi.biblio"><info><title>Bibliography</title></info> 1075 1076 <biblioentry xml:id="biblio.abicheck"> 1077 <title> 1078 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1079 xlink:href="http://abicheck.sourceforge.net"> 1080 ABIcheck 1081 </link> 1082 </title> 1083 </biblioentry> 1084 1085 <biblioentry xml:id="biblio.cxxabi"> 1086 <title> 1087 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1088 xlink:href="http://mentorembedded.github.io/cxx-abi/"> 1089 C++ ABI Summary 1090 </link> 1091 </title> 1092 </biblioentry> 1093 1094 1095 <biblioentry> 1096 <title> 1097 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1098 xlink:href="https://software.intel.com/en-us/articles/intel-compilers-for-linux-compatibility-with-gnu-compilers"> 1099 Intel Compilers for Linux: Compatibility with GNU Compilers 1100 </link> 1101 </title> 1102 </biblioentry> 1103 1104 <biblioentry> 1105 <title> 1106 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1107 xlink:href="http://docs.oracle.com/cd/E23824_01/html/819-0690/index.html"> 1108 Linker and Libraries Guide (document 819-0690) 1109 </link> 1110 </title> 1111 </biblioentry> 1112 1113 1114 <biblioentry> 1115 <title> 1116 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1117 xlink:href="http://download.oracle.com/docs/cd/E19422-01/819-3689/index.html"> 1118 Sun Studio 11: C++ Migration Guide (document 819-3689) 1119 </link> 1120 </title> 1121 </biblioentry> 1122 1123 <biblioentry> 1124 <title> 1125 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1126 xlink:href="http://www.akkadia.org/drepper/dsohowto.pdf"> 1127 How to Write Shared Libraries 1128 </link> 1129 </title> 1130 1131 <author> 1132 <personname> 1133 <firstname>Ulrich</firstname><surname>Drepper</surname> 1134 </personname> 1135 </author> 1136 </biblioentry> 1137 1138 <biblioentry> 1139 <title> 1140 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1141 xlink:href="http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.ihi0036b/index.html"> 1142 C++ ABI for the ARM Architecture 1143 </link> 1144 </title> 1145 </biblioentry> 1146 1147 <biblioentry> 1148 <title> 1149 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1150 xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n1976.html"> 1151 Dynamic Shared Objects: Survey and Issues 1152 </link> 1153 </title> 1154 1155 <subtitle> 1156 ISO C++ J16/06-0046 1157 </subtitle> 1158 <author><personname><firstname>Benjamin</firstname><surname>Kosnik</surname></personname></author> 1159 </biblioentry> 1160 1161 <biblioentry> 1162 <title> 1163 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1164 xlink:href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2013.html"> 1165 Versioning With Namespaces 1166 </link> 1167 </title> 1168 <subtitle> 1169 ISO C++ J16/06-0083 1170 </subtitle> 1171 <author><personname><firstname>Benjamin</firstname><surname>Kosnik</surname></personname></author> 1172 </biblioentry> 1173 1174 <biblioentry> 1175 <title> 1176 <link xmlns:xlink="http://www.w3.org/1999/xlink" 1177 xlink:href="http://syrcose.ispras.ru/2009/files/02_paper.pdf"> 1178 Binary Compatibility of Shared Libraries Implemented in C++ 1179 on GNU/Linux Systems 1180 </link> 1181 </title> 1182 1183 <subtitle> 1184 SYRCoSE 2009 1185 </subtitle> 1186 <author><personname><firstname>Pavel</firstname><surname>Shved</surname></personname></author> 1187 <author><personname><firstname>Denis</firstname><surname>Silakov</surname></personname></author> 1188 </biblioentry> 1189</bibliography> 1190 1191</section> 1192