| <html lang="en"> |
| <head> |
| <title>Compatibility - Using the GNU Compiler Collection (GCC)</title> |
| <meta http-equiv="Content-Type" content="text/html"> |
| <meta name="description" content="Using the GNU Compiler Collection (GCC)"> |
| <meta name="generator" content="makeinfo 4.13"> |
| <link title="Top" rel="start" href="index.html#Top"> |
| <link rel="prev" href="Objective_002dC.html#Objective_002dC" title="Objective-C"> |
| <link rel="next" href="Gcov.html#Gcov" title="Gcov"> |
| <link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> |
| <!-- |
| Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998, |
| 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, |
| 2008 Free Software Foundation, Inc. |
| |
| Permission is granted to copy, distribute and/or modify this document |
| under the terms of the GNU Free Documentation License, Version 1.2 or |
| any later version published by the Free Software Foundation; with the |
| Invariant Sections being ``Funding Free Software'', the Front-Cover |
| Texts being (a) (see below), and with the Back-Cover Texts being (b) |
| (see below). A copy of the license is included in the section entitled |
| ``GNU Free Documentation License''. |
| |
| (a) The FSF's Front-Cover Text is: |
| |
| A GNU Manual |
| |
| (b) The FSF's Back-Cover Text is: |
| |
| You have freedom to copy and modify this GNU Manual, like GNU |
| software. Copies published by the Free Software Foundation raise |
| funds for GNU development.--> |
| <meta http-equiv="Content-Style-Type" content="text/css"> |
| <style type="text/css"><!-- |
| pre.display { font-family:inherit } |
| pre.format { font-family:inherit } |
| pre.smalldisplay { font-family:inherit; font-size:smaller } |
| pre.smallformat { font-family:inherit; font-size:smaller } |
| pre.smallexample { font-size:smaller } |
| pre.smalllisp { font-size:smaller } |
| span.sc { font-variant:small-caps } |
| span.roman { font-family:serif; font-weight:normal; } |
| span.sansserif { font-family:sans-serif; font-weight:normal; } |
| --></style> |
| <link rel="stylesheet" type="text/css" href="../cs.css"> |
| </head> |
| <body> |
| <div class="node"> |
| <a name="Compatibility"></a> |
| <p> |
| Next: <a rel="next" accesskey="n" href="Gcov.html#Gcov">Gcov</a>, |
| Previous: <a rel="previous" accesskey="p" href="Objective_002dC.html#Objective_002dC">Objective-C</a>, |
| Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a> |
| <hr> |
| </div> |
| |
| <h2 class="chapter">9 Binary Compatibility</h2> |
| |
| <p><a name="index-binary-compatibility-3193"></a><a name="index-ABI-3194"></a><a name="index-application-binary-interface-3195"></a> |
| Binary compatibility encompasses several related concepts: |
| |
| <dl> |
| <dt><dfn>application binary interface (ABI)</dfn><dd>The set of runtime conventions followed by all of the tools that deal |
| with binary representations of a program, including compilers, assemblers, |
| linkers, and language runtime support. |
| Some ABIs are formal with a written specification, possibly designed |
| by multiple interested parties. Others are simply the way things are |
| actually done by a particular set of tools. |
| |
| <br><dt><dfn>ABI conformance</dfn><dd>A compiler conforms to an ABI if it generates code that follows all of |
| the specifications enumerated by that ABI. |
| A library conforms to an ABI if it is implemented according to that ABI. |
| An application conforms to an ABI if it is built using tools that conform |
| to that ABI and does not contain source code that specifically changes |
| behavior specified by the ABI. |
| |
| <br><dt><dfn>calling conventions</dfn><dd>Calling conventions are a subset of an ABI that specify of how arguments |
| are passed and function results are returned. |
| |
| <br><dt><dfn>interoperability</dfn><dd>Different sets of tools are interoperable if they generate files that |
| can be used in the same program. The set of tools includes compilers, |
| assemblers, linkers, libraries, header files, startup files, and debuggers. |
| Binaries produced by different sets of tools are not interoperable unless |
| they implement the same ABI. This applies to different versions of the |
| same tools as well as tools from different vendors. |
| |
| <br><dt><dfn>intercallability</dfn><dd>Whether a function in a binary built by one set of tools can call a |
| function in a binary built by a different set of tools is a subset |
| of interoperability. |
| |
| <br><dt><dfn>implementation-defined features</dfn><dd>Language standards include lists of implementation-defined features whose |
| behavior can vary from one implementation to another. Some of these |
| features are normally covered by a platform's ABI and others are not. |
| The features that are not covered by an ABI generally affect how a |
| program behaves, but not intercallability. |
| |
| <br><dt><dfn>compatibility</dfn><dd>Conformance to the same ABI and the same behavior of implementation-defined |
| features are both relevant for compatibility. |
| </dl> |
| |
| <p>The application binary interface implemented by a C or C++ compiler |
| affects code generation and runtime support for: |
| |
| <ul> |
| <li>size and alignment of data types |
| <li>layout of structured types |
| <li>calling conventions |
| <li>register usage conventions |
| <li>interfaces for runtime arithmetic support |
| <li>object file formats |
| </ul> |
| |
| <p>In addition, the application binary interface implemented by a C++ compiler |
| affects code generation and runtime support for: |
| <ul> |
| <li>name mangling |
| <li>exception handling |
| <li>invoking constructors and destructors |
| <li>layout, alignment, and padding of classes |
| <li>layout and alignment of virtual tables |
| </ul> |
| |
| <p>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 compilers 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. |
| |
| <p>Most platforms have a well-defined ABI that covers C code, but ABIs |
| that cover C++ functionality are not yet common. |
| |
| <p>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 |
| platforms, 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 vendors, bugs in the ABI, or |
| bugs in the implementation of the ABI in different compilers. |
| GCC's <samp><span class="option">-Wabi</span></samp> switch warns when G++ generates code that is |
| probably not compatible with the C++ ABI. |
| |
| <p>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. |
| |
| <p>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++ <samp><span class="option">-v</span></samp> option. |
| With default configuration options for G++ 3.3 the compile line for a |
| different C++ compiler needs to include |
| |
| <pre class="smallexample"> -I<var>gcc_install_directory</var>/include/c++/3.3 |
| </pre> |
| <p>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. |
| |
| <p>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 <samp><span class="command">g++</span></samp> driver, for example, tells the linker where |
| to find GCC's C++ library (<samp><span class="file">libstdc++</span></samp>) plus the other libraries |
| and startup files it needs, in the proper order. |
| |
| <p>If a program must use a different C++ library and it's not possible |
| to do the final link using a C++ driver that uses that library by default, |
| it is necessary to tell <samp><span class="command">g++</span></samp> the location and name of that |
| library. It might also be necessary to specify different startup files |
| and other runtime support libraries, and to suppress the use of GCC's |
| support libraries with one or more of the options <samp><span class="option">-nostdlib</span></samp>, |
| <samp><span class="option">-nostartfiles</span></samp>, and <samp><span class="option">-nodefaultlibs</span></samp>. |
| |
| <!-- Copyright (C) 1996, 1997, 1999, 2000, 2001, --> |
| <!-- 2002, 2003, 2004, 2005, 2008 Free Software Foundation, Inc. --> |
| <!-- This is part of the GCC manual. --> |
| <!-- For copying conditions, see the file gcc.texi. --> |
| </body></html> |
| |