C++ applications often dependent on specific language support
+routines, say for throwing exceptions, or catching exceptions, and
+perhaps also dependent on features in the C++ Standard Library.
+
+
+
The C++ Standard Library has many include files, types defined in
+those include files, specific named functions, and other behavior. The
+text of these behaviors, as written in source include files, is called
+the Application Programing Interface, or API.
+
+
+
Furthermore, C++ source that is compiled into object files is
+ transformed by the compiler: it arranges objects with specific
+ alignment and in a particular layout, mangling names according to a
+ well-defined algorithm, has specific arrangements for the support of
+ virtual functions, etc. These details are defined as the compiler
+ Application Binary Interface, or ABI. The GNU C++ compiler uses an
+ industry-standard C++ ABI starting with version 3. Details can be
+ found in the
+ ABI specification.
+
+
+
+ The GNU C++ compiler, g++, has a compiler command line option to
+ switch between various different C++ ABIs. This explicit version
+ switch is the flag -fabi-version. In addition, some
+ g++ command line options may change the ABI as a side-effect of
+ use. Such flags include -fpack-struct and
+ -fno-exceptions, but include others: see the complete
+ list in the GCC manual under the heading Options
+ for Code Generation Conventions.
+
+
+
The configure options used when building a specific libstdc++
+version may also impact the resulting library ABI. The available
+configure options, and their impact on the library ABI, are documented
+
+here.
+
+
+
Putting all of these ideas together results in the C++ Standard
+library ABI, which is the compilation of a given library API by a
+given compiler ABI. In a nutshell:
+
+
+ library API + compiler ABI = library ABI
+
+
+ The library ABI is mostly of interest for end-users who have
+ unresolved symbols and are linking dynamically to the C++ Standard
+ library, and who thus must be careful to compile their application
+ with a compiler that is compatible with the available C++ Standard
+ library binary. In this case, compatible is defined with the equation
+ above: given an application compiled with a given compiler ABI and
+ library API, it will work correctly with a Standard C++ Library
+ created with the same constraints.
+
+
+
+ To use a specific version of the C++ ABI, one must use a
+ corresponding GNU C++ toolchain (Ie, g++ and libstdc++) that
+ implements the C++ ABI in question.
+
The C++ interface has evolved throughout the history of the GNU
+C++ toolchain. With each release, various details have been changed so
+as to give distinct versions to the C++ interface.
+
Extending existing, stable ABIs. Versioning gives subsequent stable
+releases series libraries the ability to add new symbols and add
+functionality, all the while retaining backwards compatibility with
+the previous releases in the series. Note: the reverse is not true. It
+is not possible to take binaries linked with the latest version of a
+release series (if symbols have been added) and expect the initial
+release of the series to remain link compatible.
+
+
+
Allows multiple, incompatible ABIs to coexist at the same time.
+
+ How can this complexity be managed? What does C++ versioning mean?
+ Because library and compiler changes often make binaries compiled
+ with one version of the GNU tools incompatible with binaries
+ compiled with other (either newer or older) versions of the same GNU
+ tools, specific techniques are used to make managing this complexity
+ easier.
+
+
+
+ The following techniques are used:
+
+
+
+
+
Release versioning on the libgcc_s.so binary. This is
+implemented via file names and the ELF DT_SONAME mechanism (at least
+on ELF systems).
+
+
It is versioned as follows:
+
+
+
gcc-3.0.0: libgcc_s.so.1
+
gcc-3.0.1: libgcc_s.so.1
+
gcc-3.0.2: libgcc_s.so.1
+
gcc-3.0.3: libgcc_s.so.1
+
gcc-3.0.4: libgcc_s.so.1
+
gcc-3.1.0: libgcc_s.so.1
+
gcc-3.1.1: libgcc_s.so.1
+
gcc-3.2.0: libgcc_s.so.1
+
gcc-3.2.1: libgcc_s.so.1
+
gcc-3.2.2: libgcc_s.so.1
+
gcc-3.2.3: libgcc_s.so.1
+
gcc-3.3.0: libgcc_s.so.1
+
gcc-3.3.1: libgcc_s.so.1
+
gcc-3.3.2: libgcc_s.so.1
+
gcc-3.3.3: libgcc_s.so.1
+
gcc-3.4.0: libgcc_s.so.1
+
+
+
+
+
Release versioning on the libstdc++.so binary, implemented in the same was as the libgcc_s.so binary, above.
+
+
It is versioned as follows:
+
+
+
gcc-3.0.0: libstdc++.so.3.0.0
+
gcc-3.0.1: libstdc++.so.3.0.1
+
gcc-3.0.2: libstdc++.so.3.0.2
+
gcc-3.0.3: libstdc++.so.3.0.2 (Error should be libstdc++.so.3.0.3)
It is versioned with the following labels and version definitions:
+
+
gcc-3.0.0: GCC_3.0
+
gcc-3.0.1: GCC_3.0
+
gcc-3.0.2: GCC_3.0
+
gcc-3.0.3: GCC_3.0
+
gcc-3.0.4: GCC_3.0
+
gcc-3.1.0: GCC_3.0
+
gcc-3.1.1: GCC_3.0
+
gcc-3.2.0: GCC_3.0
+
gcc-3.2.1: GCC_3.0
+
gcc-3.2.2: GCC_3.0
+
gcc-3.2.3: GCC_3.0
+
gcc-3.3.0: GCC_3.0
+
gcc-3.3.1: GCC_3.0
+
gcc-3.3.2: GCC_3.0
+
gcc-3.3.3: GCC_3.0
+
gcc-3.4.0: GCC_3.0
+
+
+
+
+
Symbol versioning on the libstdc++.so binary.
+
+
mapfile: libstdc++-v3/config/linker-map.gnu
+
It is versioned with the following labels and version
+ definitions, where the version definition is the maximum for a
+ particular release. Note, only symbol which are newly introduced
+ will use the maximum version definition. Thus, for release series
+ with the same label, but incremented version definitions, the later
+ release has both versions. (An example of this would be the
+ gcc-3.2.1 release, which has GLIBCPP_3.2.1 for new symbols and
+ GLIBCPP_3.2 for symbols that were introduced in the gcc-3.2.0
+ release.)
+
+
+
gcc-3.0.0: (Error, not versioned)
+
gcc-3.0.1: (Error, not versioned)
+
gcc-3.0.2: (Error, not versioned)
+
gcc-3.0.3: (Error, not versioned)
+
gcc-3.0.4: (Error, not versioned)
+
gcc-3.1.0: GLIBCPP_3.1, CXXABI_1
+
gcc-3.1.1: GLIBCPP_3.1, CXXABI_1
+
gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2
+
gcc-3.2.1: GLIBCPP_3.2.1, CXXABI_1.2
+
gcc-3.2.2: GLIBCPP_3.2.2, CXXABI_1.2
+
gcc-3.2.3: GLIBCPP_3.2.2, CXXABI_1.2
+
gcc-3.3.0: GLIBCPP_3.2.2, CXXABI_1.2.1
+
gcc-3.3.1: GLIBCPP_3.2.3, CXXABI_1.2.1
+
gcc-3.3.2: GLIBCPP_3.2.3, CXXABI_1.2.1
+
gcc-3.3.3: GLIBCPP_3.2.3, CXXABI_1.2.1
+
gcc-3.4.0: GLIBCXX_3.4, CXXABI_1.3
+
+
+
+
+
+
Incremental bumping of a compiler pre-defined macro,
+ __GXX_ABI_VERSION. This macro is defined as the version of the
+ compiler v3 ABI, with g++ 3.0.x being version 100. This macro will
+ be automatically defined whenever g++ is used (the curious can
+ test this by invoking g++ with the '-v' flag.)
+
+
+
+ This macro is defined in the file "lang-specs.h" in the gcc/cp directory.
+ Later versions define it in "c-common.c" in the gcc directory.
+
+
+
+ It is versioned as follows:
+
+
+
gcc-3.0.x: 100
+
gcc-3.1.x: 100 (Error, should be 101)
+
gcc-3.2.x: 102
+
gcc-3.3.x: 102
+
gcc-3.4.x: 1002
+
+
+
+
+
+
Changes to the default compiler option for
+ -fabi-version.
+
+
+ It is versioned as follows:
+
+
+
gcc-3.0.x: (Error, not versioned)
+
gcc-3.1.x: (Error, not versioned)
+
gcc-3.2.x: -fabi-version=1
+
gcc-3.3.x: -fabi-version=1
+
gcc-3.4.x: -fabi-version=2
+
+
+
+
+
+
Incremental bumping of a library pre-defined macro. For releases
+ before 3.4.0, the macro is __GLIBCPP__. For later releases, it's
+ __GLIBCXX__. (The libstdc++ project generously changed from CPP to
+ CXX throughout its source to allow the "C" pre-processor the CPP
+ macro namespace.) These macros are defined as the date the library
+ was released, in compressed ISO date format, as an unsigned long.
+
+
+
+ In addition, the pre-defined macro is defined in the file
+ "c++config" in the "libstdc++-v3/include/bits" directory and is
+ changed every night by an automated script.
+
+
+ It is versioned as follows:
+
+
+
gcc-3.0.0: 20010615
+
gcc-3.0.1: 20010819
+
gcc-3.0.2: 20011023
+
gcc-3.0.3: 20011220
+
gcc-3.0.4: 20020220
+
gcc-3.1.0: 20020514
+
gcc-3.1.1: 20020725
+
gcc-3.2.0: 20020814
+
gcc-3.2.1: 20021119
+
gcc-3.2.2: 20030205
+
gcc-3.2.3: 20030422
+
gcc-3.3.0: 20030513
+
gcc-3.3.1: 20030804
+
gcc-3.3.2: 20031016
+
gcc-3.3.3: 20040214
+
gcc-3.4.0: 20040419
+
+
+
+
+
+
+
+ Incremental bumping of a library pre-defined macro,
+ _GLIBCPP_VERSION. This macro is defined as the released version of
+ the library, as a string literal. This is only implemented in
+ gcc-3.1.0 releases and higher, and is deprecated in 3.4.
+
+
+
+ This macro is defined in the file "c++config" in the
+ "libstdc++-v3/include/bits" directory and is generated
+ automatically by autoconf as part of the configure-time generation
+ of config.h.
+
+
+
+ It is versioned as follows:
+
+
+
gcc-3.0.0: "3.0.0"
+
gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")
+
gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")
+
gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")
+
gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")
+
gcc-3.1.0: "3.1.0"
+
gcc-3.1.1: "3.1.1"
+
gcc-3.2.0: "3.2"
+
gcc-3.2.1: "3.2.1"
+
gcc-3.2.2: "3.2.2"
+
gcc-3.2.3: "3.2.3"
+
gcc-3.3.0: "3.3"
+
gcc-3.3.1: "3.3.1"
+
gcc-3.3.2: "3.3.2"
+
gcc-3.3.3: "3.3.3"
+
gcc-3.4.0: "version-unused"
+
+
+
+
+
+
+ Matching each specific C++ compiler release to a specific set of
+ C++ include files. This is only implemented in gcc-3.1.1 releases
+ and higher.
+
+
+ All C++ includes are installed in include/c++, then nest in a
+ directory hierarchy corresponding to the C++ compiler's released
+ version. This version corresponds to the variable "gcc_version" in
+ "libstdc++-v3/acinclude.m4," and more details can be found in that
+ file's macro GLIBCPP_CONFIGURE.
+
+
+ C++ includes are versioned as follows:
+
+
+
gcc-3.0.0: include/g++-v3
+
gcc-3.0.1: include/g++-v3
+
gcc-3.0.2: include/g++-v3
+
gcc-3.0.3: include/g++-v3
+
gcc-3.0.4: include/g++-v3
+
gcc-3.1.0: include/g++-v3
+
gcc-3.1.1: include/c++/3.1.1
+
gcc-3.2.0: include/c++/3.2
+
gcc-3.2.1: include/c++/3.2.1
+
gcc-3.2.2: include/c++/3.2.2
+
gcc-3.2.3: include/c++/3.2.3
+
gcc-3.3.0: include/c++/3.3
+
gcc-3.3.1: include/c++/3.3.1
+
gcc-3.3.2: include/c++/3.3.2
+
gcc-3.3.3: include/c++/3.3.3
+
gcc-3.4.0: include/c++/3.4.0
+
+
+
+
+
+ Taken together, these techniques can accurately specify interface
+ and implementation changes in the GNU C++ tools themselves. Used
+ properly, they allow both the GNU C++ tools implementation, and
+ programs using them, an evolving yet controlled development that
+ maintains backward compatibility.
+
+ Minimum environment that supports a versioned ABI: A supported
+ dynamic linker, a GNU linker of sufficient vintage to understand
+ demangled C++ name globbing (ld), a shared executable compiled with
+ g++, and shared libraries (libgcc_s, libstdc++-v3) compiled by a
+ compiler (g++) with a compatible ABI. Phew.
+
+
+
+ On top of all that, an additional constraint: libstdc++ did not
+ attempt to version symbols (or age gracefully, really) until version
+ 3.1.0.
+
+
+
+ Most modern Linux and BSD versions, particularly ones using
+ gcc-3.1.x tools and more recent vintages, will meet the requirements above.
+
+ It turns out that most of the configure options that change default
+ behavior will impact the mangled names of exported symbols, and thus
+ impact versioning and compatibility.
+
+
+
+ For more information on configure options, including ABI impacts, see:
+ http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
+
+
+
+ There is one flag that explicitly deals with symbol versioning:
+ --enable-symvers.
+
+
+
+ In particular, libstdc++-v3/acinclude.m4 has a macro called
+ GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument passed
+ in via --enable-symvers=foo). At that point, the macro attempts to
+ make sure that all the requirement for symbol versioning are in
+ place. For more information, please consult acinclude.m4.
+
+ When the GNU C++ library is being built with symbol versioning on,
+ you should see the following at configure time for libstdc++-v3:
+
+
+
+ checking versioning on shared library symbols... gnu
+
+
+ If you don't see this line in the configure output, or if this line
+ appears but the last word is 'no', then you are out of luck.
+
+
+
+ If the compiler is pre-installed, a quick way to test is to compile
+ the following (or any) simple C++ file and link it to the shared
+ libstdc++ library:
+
+The following non-exhaustive list will cause the library major version
+number to increase, say from "libstdc++.so.3.0.4" to
+"libstdc++.so.4.0.0".
+
+
+
changes in the gcc/g++ compiler ABI
+
changing size of an exported symbol
+
changing alignment of an exported symbol
+
changing the layout of an exported symbol
+
changing mangling on an exported symbol
+
deleting an exported symbol
+
changing the inheritance properties of a type by adding or removing
+ base classes
+
+ changing the size, alignment, or layout of types
+ specified in the C++ standard. These may not necessarily be
+ instantiated or otherwise exported in the library binary, and
+ include all the required locale facets, as well as things like
+ std::basic_streambuf, et al.
+
This is accomplished by two techniques that separate the API from
+the ABI: forcing undefined references to link against a library binary
+for definitions.
+
+
+
+
Include files have declarations, source files have defines
+
+
For non-templatized types, such as much of class
+locale, the appropriate standard C++ include, say
+locale, can contain full declarations, while various
+source files (say locale.cc, locale_init.cc,
+localename.cc) contain definitions.
+
+
Extern template on required types
+
+
For parts of the standard that have an explicit list of required
+ instantiations, the GNU extension syntax extern template
+ can be used to control where template definitions
+ reside. By marking required instantiations as extern
+ template in include files, and providing explicit
+ instantiations in the appropriate instantiation files, non-inlined
+ template functions can be versioned. This technique is mostly used
+ on parts of the standard that require char and
+ wchar_t instantiations, and includes
+ basic_string, the locale facets, and the types in
+ iostreams.
+
+
+
In addition, these techniques have the additional benefit that
+ they reduce binary size, which can increase runtime performance.
+
+
+
Namespaces linking symbol definitions to export mapfiles
+
+
All symbols in the shared library binary are processed by a linker
+script at build time that either allows or disallows external
+linkage. Because of this, some symbols, regardless of normal C/C++
+linkage, are not visible. Symbols that are internal have several
+appealing characteristics: by not exporting the symbols, there are no
+relocations when the shared library is started and thus this makes for
+faster runtime loading performance by the underlying dynamic loading
+mechanism. In addition, they have the possibility of changing without
+impacting ABI compatibility.
+
+
+
The following namespaces are transformed by the mapfile:
+
+
+
namespace std
+
Defaults to exporting all symbols in label
+GLIBCXX that do not begin with an underscore, ie
+__test_func would not be exported by default. Select
+exceptional symbols are allowed to be visible.
+
+
namespace __gnu_cxx
+
Defaults to not exporting any symbols in label
+GLIBCXX, select items are allowed to be visible.
+
+
namespace __gnu_internal
+
Defaults to not exported, no items are allowed to be visible.
+
+
namespace __cxxabiv1, aliased to namespace abi
+
Defaults to not exporting any symbols in label
+CXXABI, select items are allowed to be visible.
+
+
+
+
+
Freezing the API
+
Disallowed changes, as above, are not made on a stable release
+branch. Enforcement tends to be less strict with GNU extensions that
+standard includes.
+Testing for GNU C++ ABI changes is composed of two distinct areas:
+testing the C++ compiler (g++) for compiler changes, and testing the
+C++ library (libstdc++) for library changes.
+
+
+
+Testing the C++ compiler ABI can be done various ways.
+
+
+
+One.
+Intel ABI checker. More information can be obtained
+here.
+
+
+
+Two.
+The second is yet unreleased, but has been announced on the gcc
+mailing list. It is yet unspecified if these tools will be freely
+available, and able to be included in a GNU project. Please contact
+Mark Mitchell (mark@codesourcery.com) for more details, and current
+status.
+
+
+
+Three.
+Involves using the vlad.consistency test framework. This has also been
+discussed on the gcc mailing lists.
+
+
+
+Testing the C++ library ABI can also be done various ways.
+
+
+
+One.
+(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
+one with a new compiler and an old library, and the other with an old
+compiler and a new library, and look for testsuite regressions)
+
+
+
+Details on how to set this kind of test up can be found here:
+http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
+
+
+
+Two.
+Use the 'make check-abi' rule in the libstdc++-v3 Makefile.
+
+
+
+This is a proactive check the library ABI. Currently, exported symbol
+names that are either weak or defined are checked against a last known
+good baseline. Currently, this baseline is keyed off of 3.2.0
+binaries, as this was the last time the .so number was incremented. In
+addition, all exported names are demangled, and the exported objects
+are checked to make sure they are the same size as the same object in
+the baseline.
+
+
+
+This dataset is insufficient, yet a start. Also needed is a
+comprehensive check for all user-visible types part of the standard
+library for sizeof() and alignof() changes.
+
+
+
+Verifying compatible layouts of objects is not even attempted. It
+should be possible to use sizeof, alignof, and offsetof to compute
+offsets for each structure and type in the standard library, saving to
+another datafile. Then, compute this in a similar way for new
+binaries, and look for differences.
+
+
+
+Another approach might be to use the -fdump-class-hierarchy flag to
+get information. However, currently this approach gives insufficient
+data for use in library testing, as class data members, their offsets,
+and other detailed data is not displayed with this flag.
+(See g++/7470 on how this was used to find bugs.)
+
+
+
+Perhaps there are other C++ ABI checkers. If so, please notify
+us. We'd like to know about them!
+
+A "C" application, dynamically linked to two shared libraries, liba,
+libb. The dependent library liba is C++ shared library compiled with
+gcc-3.3.x, and uses io, exceptions, locale, etc. The dependent library
+libb is a C++ shared library compiled with gcc-3.4.x, and also uses io,
+exceptions, locale, etc.
+
+This resulting binary, when executed, will be able to safely use code
+from both liba, and the dependent libstdc++.so.6, and libb, with the
+dependent libstdc++.so.5.
+
+ABIcheck, a vague idea of checking ABI compatibility
+http://abicheck.sourceforge.net/
+
+
+C++ ABI reference
+http://www.codesourcery.com/cxx-abi/
+
+
+
+Intel ABI documentation
+"Intel® Compilers for Linux* -Compatibility with the GNU Compilers"
+(included in icc 6.0)
+
+
+
+Sun Solaris 2.9 docs
+Linker and Libraries Guide (document 816-1386)
+C++ Migration Guide (document 816-2459)
+http://docs.sun.com/db/prod/solaris.9
+http://docs.sun.com/?p=/doc/816-1386&a=load
+
+
+
+Ulrich Drepper, "ELF Symbol Versioning"
+http://people.redhat.com/drepper/symbol-versioning
+
diff --git a/libstdc++-v3/docs/html/abi.txt b/libstdc++-v3/docs/html/abi.txt
deleted file mode 100644
index 430108885f9..00000000000
--- a/libstdc++-v3/docs/html/abi.txt
+++ /dev/null
@@ -1,389 +0,0 @@
-
-2002-10-14 Benjamin Kosnik
-
-Description of the libstdc++ ABI.
-
-I. What is an ABI? What's covered? What's not?
-
-- scope of document, of use to system integrators.
-
-- What's the deal with C++? Why can't different compiler's object
- files link with each other? Bug? Feature?
-
-- compilation includes and linked library binary must match up..
-
-- shared library only, static is immutable.
-
-- What's an ABI?
-
-- library ABI, compiler ABI different issues, (but related)
-
-- GNU C++ does not have a compiler command line option to switch
- between various different C++ ABIs. For instance, there is no way to
- switch between the gcc-3.0.x ABI, gcc-3.1.x ABI, and the gcc-3.2.x
- ABI during compilation. Other C++ compilers do allow this, and some
- g++ command line options may change the ABI (-fno-exceptions, see
- the complete list), but there is no version switch. Sorry.
-
- To use a specific C++ABI, one must use the corresponding GNU C++
- toolchain.
-
-- How can this complexity be managed? What does C++ versioning mean?
- Because library and compiler changes often make binaries compiled
- with one version of the GNU tools incompatible with binaries
- compiled with other (either newer or older) versions of the same GNU
- tools, specific techniques are used to make managing this complexity
- easier.
-
- The following techniques are used:
-
- - Release versioning on the libgcc_s.so binary.
-
- It is versioned as follows:
- gcc-3.0.0: libgcc_s.so.1
- gcc-3.0.1: libgcc_s.so.1
- gcc-3.0.2: libgcc_s.so.1
- gcc-3.0.3: libgcc_s.so.1
- gcc-3.0.4: libgcc_s.so.1
- gcc-3.1.0: libgcc_s.so.1
- gcc-3.1.1: libgcc_s.so.1
- gcc-3.2.0: libgcc_s.so.1
-
-
- - Release versioning on the libstdc++.so binary.
-
- It is versioned as follows:
- gcc-3.0.0: libstdc++.so.3.0.0
- gcc-3.0.1: libstdc++.so.3.0.1
- gcc-3.0.2: libstdc++.so.3.0.2
- gcc-3.0.3: libstdc++.so.3.0.2 (Error, should be libstdc++.so.3.0.3)
- gcc-3.0.4: libstdc++.so.3.0.4
- gcc-3.1.0: libstdc++.so.4.0.0
- gcc-3.1.1: libstdc++.so.4.0.1
- gcc-3.2.0: libstdc++.so.5.0.0
-
-
- - Symbol versioning on the libgcc_s.so binary.
-
- file: gcc/libgcc-std.ver
-
- It is versioned as follows:
- gcc-3.0.0: GCC_3.0
- gcc-3.0.1: GCC_3.0
- gcc-3.0.2: GCC_3.0
- gcc-3.0.3: GCC_3.0
- gcc-3.0.4: GCC_3.0
- gcc-3.1.0: GCC_3.0
- gcc-3.1.1: GCC_3.0
- gcc-3.2.0: GCC_3.0
-
-
- - Symbol versioning on the libstdc++.so binary.
-
- It is versioned as follows:
- gcc-3.0.0: (Error, unversioned)
- gcc-3.0.1: (Error, unversioned)
- gcc-3.0.2: (Error, unversioned)
- gcc-3.0.3: (Error, unversioned)
- gcc-3.0.4: (Error, unversioned)
- gcc-3.1.0: GLIBCPP_3.1, CXXABI_1
- gcc-3.1.1: GLIBCPP_3.1, CXXABI_1
- gcc-3.2.0: GLIBCPP_3.2, CXXABI_1.2
-
- file: libstdc++-v3/config/linker-map.gnu
-
-
- - Incremental bumping of a compiler pre-defined macro,
- __GXX_ABI_VERSION. This macro is defined as the version of the
- compiler v3 ABI, with g++ 3.0.x being version 100. This macro will
- be automatically defined whenever g++ is used (the curious can
- test this by invoking g++ with the '-v' flag.)
-
- This macro is defined in the file "lang-specs.h" in the gcc/cp directory.
- Later versions define it in "c-common.c" in the gcc directory.
-
- It is versioned as follows:
- gcc-3.0.x: 100
- gcc-3.1.x: 100 (Error, should be 101)
- gcc-3.2.x: 102
-
-
- - Incremental bumping of a library pre-defined macro, __GLIBCPP__ or
- __GLIBCXX__. This macro is defined as the date the library was
- released, in compressed ISO date format, as an unsigned long.
-
- This macro is defined in the file "c++config" in the
- "libstdc++-v3/include/bits" directory and is changed every night
- by an automated script.
-
- It is versioned as follows:
- gcc-3.0.0: 20010615
- gcc-3.0.1: 20010819
- gcc-3.0.2: 20011023
- gcc-3.0.3: 20011220
- gcc-3.0.4: 20020220
- gcc-3.1.0: 20020514
- gcc-3.1.1: 20020725
- gcc-3.2.0: 20020814
-
-
- - Incremental bumping of a library pre-defined macro,
- _GLIBCPP_VERSION. This macro is defined as the released version of
- the library, as a string literal. This is only implemented in
- gcc-3.1.0 releases and higher, and changed to _GLIBCXX_VERSION in 3.4.
-
- This macro is defined in the file "c++config" in the
- "libstdc++-v3/include/bits" directory and is generated
- automatically by autoconf as part of the configure-time generation
- of config.h.
-
- It is versioned as follows:
- gcc-3.0.0: "3.0.0"
- gcc-3.0.1: "3.0.0" (Error, should be "3.0.1")
- gcc-3.0.2: "3.0.0" (Error, should be "3.0.2")
- gcc-3.0.3: "3.0.0" (Error, should be "3.0.3")
- gcc-3.0.4: "3.0.0" (Error, should be "3.0.4")
- gcc-3.1.0: "3.1.0"
- gcc-3.1.1: "3.1.1"
- gcc-3.2.0: "3.2"
-
-
- - Matching each specific C++ compiler release to a specific set of
- C++ include files. This is only implemented in gcc-3.1.1 releases
- and higher.
-
- All C++ includes are installed in include/c++, then nest in a
- directory hierarchy corresponding to the C++ compiler's released
- version. This version corresponds to the variable "gcc_version" in
- "libstdc++-v3/acinclude.m4," and more details can be found in that
- file's macro GLIBCPP_CONFIGURE.
-
- C++ includes are versioned as follows:
- gcc-3.0.0: include/g++-v3
- gcc-3.0.1: include/g++-v3
- gcc-3.0.2: include/g++-v3
- gcc-3.0.3: include/g++-v3
- gcc-3.0.4: include/g++-v3
- gcc-3.1.0: include/g++-v3
- gcc-3.1.1: include/c++/3.1.1
- gcc-3.2.0: include/c++/3.2
-
- Taken together, these techniques can accurately specify interface
- and implementation changes in the GNU C++ tools themselves. Used
- properly, they allow both the GNU C++ tools implementation, and
- programs using them, an evolving yet controlled development that
- maintains backward compatibility.
-
-- Minimum environment that supports a versioned ABI: what's needed? A
- supported dynamic linker, a GNU linker of sufficient vintage to
- understand demangled C++ name globbing (ld), a shared executable
- compiled with g++, and shared libraries (libgcc_s, libstdc++-v3)
- compiled by a compiler (g++) with a compatible ABI. Phew.
-
- On top of all that, an additional constraint: libstdc++ did not
- attempt to version symbols (or age gracefully, really) until version
- 3.1.0.
-
- Most modern Linux and BSD versions, particularly ones using
- gcc-3.1.x tools, will meet the requirements above.
-
-- What configure options impact symbol versioning?
-
- It turns out that most of the configure options that change default
- behavior will impact the mangled names of exported symbols, and thus
- impact versioning and compatibility.
-
- For more information on configure options, including ABI impacts, see:
- http://gcc.gnu.org/onlinedocs/libstdc++/configopts.html
-
- There is one flag that explicitly deals with symbol versioning:
- --enable-symvers.
-
- In particular, libstdc++-v3/acinclude.m4 has a macro called
- GLIBCXX_ENABLE_SYMVERS that defaults to yes (or the argument passed
- in via --enable-symvers=foo). At that point, the macro attempts to
- make sure that all the requirement for symbol versioning are in
- place. For more information, please consult acinclude.m4.
-
-- How can I tell if symbol versioning is, indeed, active?
-
- When the GNU C++ library is being built with symbol versioning on,
- you should see the following at configure time for libstdc++-v3:
-
- checking versioning on shared library symbols... gnu
-
- If you don't see this line in the configure output, or if this line
- appears but the last word is 'no', then you are out of luck.
-
- If the compiler is pre-installed, a quick way to test is to compile
- the following (or any) simple C++ file:
-
-#include
-
-int main()
-{ std::cout << "hello" << std::endl; return 0; }
-
-%g++ hello.cc -o hello.out
-%nm hello.out
-
-If you see symbols in the resulting output with "GLIBCPP_3.x" as part
-of the name, then the executable is versioned. Here's an example:
-
- U _ZNSt8ios_base4InitC1Ev@@GLIBCPP_3.1
-
-
-II. Library ABI changes
-
-The following will cause the library major version number to
-increase, say from "libstdc++.so.3.0.4" to "libstdc++.so.4.0.0".
-
-- (anything) changing in the gcc/g++ compiler ABI
-
-- (anything) changing size of an exported symbol
-
-- (anything) changing alignment of an exported symbol
-
-- (anything) changing the layout of an exported symbol
-
-- (anything) changing mangling on an exported symbol
-
-- (anything) deleting an exported symbol
-
-- (anything) changing the size, alignment, or layout of types
- specified in the C++ standard. These may not necessarily be
- instantiated or otherwise exported in the library binary, and
- include all the required locale facets, as well as things like
- std::basic_streambuf, et al.
-
-Note: adding an exported symbol, if it's in a new and dependent
-interface name, is ok.
-
-The following will cause the library revision version number to
-increase, say from "libstdc++.so.5.0.0" to "libstdc++.so.5.0.1".
-
-- any release of the gcc toolchain.
-
-
-III. Versioning
-
-- include files
-
- - versioning headers with version, why necessary
- (need to control member/non-member functions, add delete files)
-
-- shared library binaries
-
- - release versions
-
- - libtool versions
-
- - when does so version get a bump? what are the options?
-
- - how is the link map used?
-
- - in an non-abi breaking minor release, how are symbols added?
- removed?
-
- - in an abi-breaking major release, what happens? symbol fall back
-
-
-IV. Testing ABI changes
-
-Testing for GNU C++ ABI changes is composed of two distinct areas:
-testing the C++ compiler (g++) for compiler changes, and testing the
-C++ library (libstdc++) for library changes.
-
-Testing the C++ compiler ABI can be done various ways.
-
-One.
-Intel ABI checker. More information can be obtained
-here.
-
-Two.
-The second is yet unreleased, but has been announced on the gcc
-mailing list. It is yet unspecified if these tools will be freely
-available, and able to be included in a GNU project. Please contact
-Mark Mitchell (mark@codesourcery.com) for more details, and current
-status.
-
-Three.
-Involves using the vlad.consistency test framework. This has also been
-discussed on the gcc mailing lists.
-
-Testing the C++ library ABI can also be done various ways.
-
-One.
-(Brendan Kehoe, Jeff Law suggestion to run 'make check-c++' two ways,
-one with a new compiler and an old library, and the other with an old
-compiler and a new library, and look for testsuite regressions)
-
-Details on how to set this kind of test up can be found here:
-http://gcc.gnu.org/ml/gcc/2002-08/msg00142.html
-
-Two.
-Use the 'make check-abi' rule in the libstdc++-v3 Makefile.
-
-This is a proactive check the library ABI. Currently, exported symbol
-names that are either weak or defined are checked against a last known
-good baseline. Currently, this baseline is keyed off of 3.2.0
-binaries, as this was the last time the .so number was incremented. In
-addition, all exported names are demangled, and the exported objects
-are checked to make sure they are the same size as the same object in
-the baseline.
-
-This dataset is insufficient, yet a start. Also needed is a
-comprehensive check for all user-visible types part of the standard
-library for sizeof() and alignof() changes.
-
-Verifying compatible layouts of objects is not even attempted. It
-should be possible to use sizeof, alignof, and offsetof to compute
-offsets for each structure and type in the standard library, saving to
-another datafile. Then, compute this in a similar way for new
-binaries, and look for differences.
-
-Another approach might be to use the -fdump-class-hierarchy flag to
-get information. However, currently this approach gives insufficient
-data for use in library testing, as class data members, their offsets,
-and other detailed data is not displayed with this flag.
-(See g++/7470 on how this was used to find bugs.)
-
-Perhaps there are other C++ ABI checkers. If so, please notify
-us. We'd like to know about them!
-
-
-V. Issues not directly addressed, and possible suggestions
-
-- what to do about multi-ABI systems (nathan scenario)?
-
- - compatibility libs
-
- --enable-version-specific-runtime-libs
-
- - Alexandre Oliva proposal to have extended name attributes, modify ld
-
- - directory-level versioning
-
-- wrapping C++ API's in "C" to use the C ABI.
-
-
-V. References
-
-ABIcheck, a vague idea of checking ABI compatibility
-http://abicheck.sourceforge.net/
-
-C++ ABI reference
-http://www.codesourcery.com/cxx-abi/
-
-Intel ABI documentation
-"Intel® Compilers for Linux* -Compatibility with the GNU Compilers"
-(included in icc 6.0)
-
-Sun Solaris 2.9 docs
-Linker and Libraries Guide (document 816-1386)
-C++ Migration Guide (document 816-2459)
-http://docs.sun.com/db/prod/solaris.9
-http://docs.sun.com/?p=/doc/816-1386&a=load
-
-Ulrich Drepper, "ELF Symbol Versioning"
-http://people.redhat.com/drepper/symbol-versioning
-
diff --git a/libstdc++-v3/docs/html/documentation.html b/libstdc++-v3/docs/html/documentation.html
index 7819955b66b..d1aea5a926e 100644
--- a/libstdc++-v3/docs/html/documentation.html
+++ b/libstdc++-v3/docs/html/documentation.html
@@ -30,7 +30,7 @@