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