gcc: Compatibility

1 
1 9 Binary Compatibility
1 **********************
1 
1 Binary compatibility encompasses several related concepts:
1 
1 "application binary interface (ABI)"
1      The set of runtime conventions followed by all of the tools that
1      deal with binary representations of a program, including compilers,
1      assemblers, linkers, and language runtime support.  Some ABIs are
1      formal with a written specification, possibly designed by multiple
1      interested parties.  Others are simply the way things are actually
1      done by a particular set of tools.
1 
1 "ABI conformance"
1      A compiler conforms to an ABI if it generates code that follows all
1      of the specifications enumerated by that ABI.  A library conforms
1      to an ABI if it is implemented according to that ABI.  An
1      application conforms to an ABI if it is built using tools that
1      conform to that ABI and does not contain source code that
1      specifically changes behavior specified by the ABI.
1 
1 "calling conventions"
1      Calling conventions are a subset of an ABI that specify of how
1      arguments are passed and function results are returned.
1 
1 "interoperability"
1      Different sets of tools are interoperable if they generate files
1      that can be used in the same program.  The set of tools includes
1      compilers, assemblers, linkers, libraries, header files, startup
1      files, and debuggers.  Binaries produced by different sets of tools
1      are not interoperable unless they implement the same ABI.  This
1      applies to different versions of the same tools as well as tools
1      from different vendors.
1 
1 "intercallability"
1      Whether a function in a binary built by one set of tools can call a
1      function in a binary built by a different set of tools is a subset
1      of interoperability.
1 
1 "implementation-defined features"
1      Language standards include lists of implementation-defined features
1      whose behavior can vary from one implementation to another.  Some
1      of these features are normally covered by a platform's ABI and
1      others are not.  The features that are not covered by an ABI
1      generally affect how a program behaves, but not intercallability.
1 
1 "compatibility"
1      Conformance to the same ABI and the same behavior of
1      implementation-defined features are both relevant for
1      compatibility.
1 
1  The application binary interface implemented by a C or C++ compiler
1 affects code generation and runtime support for:
1 
1    * size and alignment of data types
1    * layout of structured types
1    * calling conventions
1    * register usage conventions
1    * interfaces for runtime arithmetic support
1    * object file formats
1 
1  In addition, the application binary interface implemented by a C++
1 compiler affects code generation and runtime support for:
1    * name mangling
1    * exception handling
1    * invoking constructors and destructors
1    * layout, alignment, and padding of classes
1    * layout and alignment of virtual tables
1 
1  Some GCC compilation options cause the compiler to generate code that
1 does not conform to the platform's default ABI.  Other options cause
1 different program behavior for implementation-defined features that are
1 not covered by an ABI.  These options are provided for consistency with
1 other compilers that do not follow the platform's default ABI or the
1 usual behavior of implementation-defined features for the platform.  Be
1 very careful about using such options.
1 
1  Most platforms have a well-defined ABI that covers C code, but ABIs
1 that cover C++ functionality are not yet common.
1 
1  Starting with GCC 3.2, GCC binary conventions for C++ are based on a
1 written, vendor-neutral C++ ABI that was designed to be specific to
1 64-bit Itanium but also includes generic specifications that apply to
1 any platform.  This C++ ABI is also implemented by other compiler
1 vendors on some platforms, notably GNU/Linux and BSD systems.  We have
1 tried hard to provide a stable ABI that will be compatible with future
1 GCC releases, but it is possible that we will encounter problems that
1 make this difficult.  Such problems could include different
1 interpretations of the C++ ABI by different vendors, bugs in the ABI, or
1 bugs in the implementation of the ABI in different compilers.  GCC's
1 '-Wabi' switch warns when G++ generates code that is probably not
1 compatible with the C++ ABI.
1 
1  The C++ library used with a C++ compiler includes the Standard C++
1 Library, with functionality defined in the C++ Standard, plus language
1 runtime support.  The runtime support is included in a C++ ABI, but
1 there is no formal ABI for the Standard C++ Library.  Two
1 implementations of that library are interoperable if one follows the
1 de-facto ABI of the other and if they are both built with the same
1 compiler, or with compilers that conform to the same ABI for C++
1 compiler and runtime support.
1 
1  When G++ and another C++ compiler conform to the same C++ ABI, but the
1 implementations of the Standard C++ Library that they normally use do
1 not follow the same ABI for the Standard C++ Library, object files built
1 with those compilers can be used in the same program only if they use
1 the same C++ library.  This requires specifying the location of the C++
1 library header files when invoking the compiler whose usual library is
1 not being used.  The location of GCC's C++ header files depends on how
1 the GCC build was configured, but can be seen by using the G++ '-v'
1 option.  With default configuration options for G++ 3.3 the compile line
1 for a different C++ compiler needs to include
1 
1          -IGCC_INSTALL_DIRECTORY/include/c++/3.3
1 
1  Similarly, compiling code with G++ that must use a C++ library other
1 than the GNU C++ library requires specifying the location of the header
1 files for that other library.
1 
1  The most straightforward way to link a program to use a particular C++
1 library is to use a C++ driver that specifies that C++ library by
1 default.  The 'g++' driver, for example, tells the linker where to find
1 GCC's C++ library ('libstdc++') plus the other libraries and startup
1 files it needs, in the proper order.
1 
1  If a program must use a different C++ library and it's not possible to
1 do the final link using a C++ driver that uses that library by default,
1 it is necessary to tell 'g++' the location and name of that library.  It
1 might also be necessary to specify different startup files and other
1 runtime support libraries, and to suppress the use of GCC's support
1 libraries with one or more of the options '-nostdlib', '-nostartfiles',
1 and '-nodefaultlibs'.
1