Red Hat ENTERPRISE LINUX 3 - USING GCC Using Instructions page 234

228
interfaces for runtime arithmetic support
•
object file formats
•
In addition, the application binary interface implemented by a C++ compiler affects code generation
and runtime support for:
name mangling
•
exception handling
•
invoking constructors and destructors
•
layout, alignment, and padding of classes
•
layout and alignment of virtual tables
•
Some GCC compilation options cause the compiler to generate code that does not conform to the
platform's default ABI. Other options cause different program behavior for implementation-defined
features that are not covered by an ABI. These options are provided for consistency with other com-
pilers that do not follow the platform's default ABI or the usual behavior of implementation-defined
features for the platform. Be very careful about using such options.
Most platforms have a well-defined ABI that covers C code, but ABIs that cover C++ functionality
are not yet common.
Starting with GCC 3.2, GCC binary conventions for C++ are based on a written, vendor-neutral C++
ABI that was designed to be specific to 64-bit Itanium but also includes generic specifications that
apply to any platform. This C++ ABI is also implemented by other compiler vendors on some plat-
forms, notably GNU/Linux and BSD systems. We have tried hard to provide a stable ABI that will
be compatible with future GCC releases, but it is possible that we will encounter problems that make
this difficult. Such problems could include different interpretations of the C++ ABI by different ven-
dors, bugs in the ABI, or bugs in the implementation of the ABI in different compilers. GCC's
switch warns when G++ generates code that is probably not compatible with the C++ ABI.
The C++ library used with a C++ compiler includes the Standard C++ Library, with functionality
defined in the C++ Standard, plus language runtime support. The runtime support is included in a
C++ ABI, but there is no formal ABI for the Standard C++ Library. Two implementations of that
library are interoperable if one follows the de-facto ABI of the other and if they are both built with
the same compiler, or with compilers that conform to the same ABI for C++ compiler and runtime
support.
When G++ and another C++ compiler conform to the same C++ ABI, but the implementations of
the Standard C++ Library that they normally use do not follow the same ABI for the Standard C++
Library, object files built with those compilers can be used in the same program only if they use the
same C++ library. This requires specifying the location of the C++ library header files when invoking
the compiler whose usual library is not being used. The location of GCC's C++ header files depends
on how the GCC build was configured, but can be seen by using the G++
configuration options for G++ 3.3 the compile line for a different C++ compiler needs to include
-I
gcc_install_directory
Similarly, compiling code with G++ that must use a C++ library other than the GNU C++ library
requires specifying the location of the header files for that other library.
The most straightforward way to link a program to use a particular C++ library is to use a C++ driver
that specifies that C++ library by default. The
GCC's C++ library (
libstdc++
If a program must use a different C++ library and it is not possible to do the final link using a C++
driver that uses that library by default, it is necessary to tell
brary. It might also be necessary to specify different startup files and other runtime support libraries,
/include/c++/3.3
g++
) plus the other libraries and startup files it needs, in the proper order.
Chapter 9. Binary Compatibility
driver, for example, tells the linker where to find
the location and name of that li-
g++
-Wabi
option. With default
-v