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