libstdc++-v3/doc/xml/manual/abi.xml

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