You cannot select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
189 lines
9.2 KiB
HTML
189 lines
9.2 KiB
HTML
<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-2015 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.3 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>
|
|
</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-4238"></a><a name="index-ABI-4239"></a><a name="index-application-binary-interface-4240"></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-2015 Free Software Foundation, Inc. -->
|
|
<!-- This is part of the GCC manual. -->
|
|
<!-- For copying conditions, see the file gcc.texi. -->
|
|
</body></html>
|
|
|