1<html lang="en"> 2<head> 3<title>Compatibility - Using the GNU Compiler Collection (GCC)</title> 4<meta http-equiv="Content-Type" content="text/html"> 5<meta name="description" content="Using the GNU Compiler Collection (GCC)"> 6<meta name="generator" content="makeinfo 4.13"> 7<link title="Top" rel="start" href="index.html#Top"> 8<link rel="prev" href="Objective_002dC.html#Objective_002dC" title="Objective-C"> 9<link rel="next" href="Gcov.html#Gcov" title="Gcov"> 10<link href="http://www.gnu.org/software/texinfo/" rel="generator-home" title="Texinfo Homepage"> 11<!-- 12Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 131998, 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 142010 Free Software Foundation, Inc. 15 16Permission is granted to copy, distribute and/or modify this document 17under the terms of the GNU Free Documentation License, Version 1.3 or 18any later version published by the Free Software Foundation; with the 19Invariant Sections being ``Funding Free Software'', the Front-Cover 20Texts being (a) (see below), and with the Back-Cover Texts being (b) 21(see below). A copy of the license is included in the section entitled 22``GNU Free Documentation License''. 23 24(a) The FSF's Front-Cover Text is: 25 26 A GNU Manual 27 28(b) The FSF's Back-Cover Text is: 29 30 You have freedom to copy and modify this GNU Manual, like GNU 31 software. Copies published by the Free Software Foundation raise 32 funds for GNU development.--> 33<meta http-equiv="Content-Style-Type" content="text/css"> 34<style type="text/css"><!-- 35 pre.display { font-family:inherit } 36 pre.format { font-family:inherit } 37 pre.smalldisplay { font-family:inherit; font-size:smaller } 38 pre.smallformat { font-family:inherit; font-size:smaller } 39 pre.smallexample { font-size:smaller } 40 pre.smalllisp { font-size:smaller } 41 span.sc { font-variant:small-caps } 42 span.roman { font-family:serif; font-weight:normal; } 43 span.sansserif { font-family:sans-serif; font-weight:normal; } 44--></style> 45<link rel="stylesheet" type="text/css" href="../cs.css"> 46</head> 47<body> 48<div class="node"> 49<a name="Compatibility"></a> 50<p> 51Next: <a rel="next" accesskey="n" href="Gcov.html#Gcov">Gcov</a>, 52Previous: <a rel="previous" accesskey="p" href="Objective_002dC.html#Objective_002dC">Objective-C</a>, 53Up: <a rel="up" accesskey="u" href="index.html#Top">Top</a> 54<hr> 55</div> 56 57<h2 class="chapter">9 Binary Compatibility</h2> 58 59<p><a name="index-binary-compatibility-3289"></a><a name="index-ABI-3290"></a><a name="index-application-binary-interface-3291"></a> 60Binary compatibility encompasses several related concepts: 61 62 <dl> 63<dt><dfn>application binary interface (ABI)</dfn><dd>The set of runtime conventions followed by all of the tools that deal 64with binary representations of a program, including compilers, assemblers, 65linkers, and language runtime support. 66Some ABIs are formal with a written specification, possibly designed 67by multiple interested parties. Others are simply the way things are 68actually done by a particular set of tools. 69 70 <br><dt><dfn>ABI conformance</dfn><dd>A compiler conforms to an ABI if it generates code that follows all of 71the specifications enumerated by that ABI. 72A library conforms to an ABI if it is implemented according to that ABI. 73An application conforms to an ABI if it is built using tools that conform 74to that ABI and does not contain source code that specifically changes 75behavior specified by the ABI. 76 77 <br><dt><dfn>calling conventions</dfn><dd>Calling conventions are a subset of an ABI that specify of how arguments 78are passed and function results are returned. 79 80 <br><dt><dfn>interoperability</dfn><dd>Different sets of tools are interoperable if they generate files that 81can be used in the same program. The set of tools includes compilers, 82assemblers, linkers, libraries, header files, startup files, and debuggers. 83Binaries produced by different sets of tools are not interoperable unless 84they implement the same ABI. This applies to different versions of the 85same tools as well as tools from different vendors. 86 87 <br><dt><dfn>intercallability</dfn><dd>Whether a function in a binary built by one set of tools can call a 88function in a binary built by a different set of tools is a subset 89of interoperability. 90 91 <br><dt><dfn>implementation-defined features</dfn><dd>Language standards include lists of implementation-defined features whose 92behavior can vary from one implementation to another. Some of these 93features are normally covered by a platform's ABI and others are not. 94The features that are not covered by an ABI generally affect how a 95program behaves, but not intercallability. 96 97 <br><dt><dfn>compatibility</dfn><dd>Conformance to the same ABI and the same behavior of implementation-defined 98features are both relevant for compatibility. 99</dl> 100 101 <p>The application binary interface implemented by a C or C++ compiler 102affects code generation and runtime support for: 103 104 <ul> 105<li>size and alignment of data types 106<li>layout of structured types 107<li>calling conventions 108<li>register usage conventions 109<li>interfaces for runtime arithmetic support 110<li>object file formats 111</ul> 112 113 <p>In addition, the application binary interface implemented by a C++ compiler 114affects code generation and runtime support for: 115 <ul> 116<li>name mangling 117<li>exception handling 118<li>invoking constructors and destructors 119<li>layout, alignment, and padding of classes 120<li>layout and alignment of virtual tables 121</ul> 122 123 <p>Some GCC compilation options cause the compiler to generate code that 124does not conform to the platform's default ABI. Other options cause 125different program behavior for implementation-defined features that are 126not covered by an ABI. These options are provided for consistency with 127other compilers that do not follow the platform's default ABI or the 128usual behavior of implementation-defined features for the platform. 129Be very careful about using such options. 130 131 <p>Most platforms have a well-defined ABI that covers C code, but ABIs 132that cover C++ functionality are not yet common. 133 134 <p>Starting with GCC 3.2, GCC binary conventions for C++ are based on a 135written, vendor-neutral C++ ABI that was designed to be specific to 13664-bit Itanium but also includes generic specifications that apply to 137any platform. 138This C++ ABI is also implemented by other compiler vendors on some 139platforms, notably GNU/Linux and BSD systems. 140We have tried hard to provide a stable ABI that will be compatible with 141future GCC releases, but it is possible that we will encounter problems 142that make this difficult. Such problems could include different 143interpretations of the C++ ABI by different vendors, bugs in the ABI, or 144bugs in the implementation of the ABI in different compilers. 145GCC's <samp><span class="option">-Wabi</span></samp> switch warns when G++ generates code that is 146probably not compatible with the C++ ABI. 147 148 <p>The C++ library used with a C++ compiler includes the Standard C++ 149Library, with functionality defined in the C++ Standard, plus language 150runtime support. The runtime support is included in a C++ ABI, but there 151is no formal ABI for the Standard C++ Library. Two implementations 152of that library are interoperable if one follows the de-facto ABI of the 153other and if they are both built with the same compiler, or with compilers 154that conform to the same ABI for C++ compiler and runtime support. 155 156 <p>When G++ and another C++ compiler conform to the same C++ ABI, but the 157implementations of the Standard C++ Library that they normally use do not 158follow the same ABI for the Standard C++ Library, object files built with 159those compilers can be used in the same program only if they use the same 160C++ library. This requires specifying the location of the C++ library 161header files when invoking the compiler whose usual library is not being 162used. The location of GCC's C++ header files depends on how the GCC 163build was configured, but can be seen by using the G++ <samp><span class="option">-v</span></samp> option. 164With default configuration options for G++ 3.3 the compile line for a 165different C++ compiler needs to include 166 167<pre class="smallexample"> -I<var>gcc_install_directory</var>/include/c++/3.3 168</pre> 169 <p>Similarly, compiling code with G++ that must use a C++ library other 170than the GNU C++ library requires specifying the location of the header 171files for that other library. 172 173 <p>The most straightforward way to link a program to use a particular 174C++ library is to use a C++ driver that specifies that C++ library by 175default. The <samp><span class="command">g++</span></samp> driver, for example, tells the linker where 176to find GCC's C++ library (<samp><span class="file">libstdc++</span></samp>) plus the other libraries 177and startup files it needs, in the proper order. 178 179 <p>If a program must use a different C++ library and it's not possible 180to do the final link using a C++ driver that uses that library by default, 181it is necessary to tell <samp><span class="command">g++</span></samp> the location and name of that 182library. It might also be necessary to specify different startup files 183and other runtime support libraries, and to suppress the use of GCC's 184support libraries with one or more of the options <samp><span class="option">-nostdlib</span></samp>, 185<samp><span class="option">-nostartfiles</span></samp>, and <samp><span class="option">-nodefaultlibs</span></samp>. 186 187<!-- Copyright (C) 1996, 1997, 1999, 2000, 2001, 2002, 2003, 2004, 2005, --> 188<!-- 2008, 2010 Free Software Foundation, Inc. --> 189<!-- This is part of the GCC manual. --> 190<!-- For copying conditions, see the file gcc.texi. --> 191 </body></html> 192 193