|
- <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
- <html>
- <!-- Copyright (C) 1988-2020 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. -->
- <!-- Created by GNU Texinfo 6.5, http://www.gnu.org/software/texinfo/ -->
- <head>
- <meta http-equiv="Content-Type" content="text/html; charset=utf-8">
- <title>Compatibility (Using the GNU Compiler Collection (GCC))</title>
-
- <meta name="description" content="Compatibility (Using the GNU Compiler Collection (GCC))">
- <meta name="keywords" content="Compatibility (Using the GNU Compiler Collection (GCC))">
- <meta name="resource-type" content="document">
- <meta name="distribution" content="global">
- <meta name="Generator" content="makeinfo">
- <link href="index.html#Top" rel="start" title="Top">
- <link href="Option-Index.html#Option-Index" rel="index" title="Option Index">
- <link href="index.html#SEC_Contents" rel="contents" title="Table of Contents">
- <link href="index.html#Top" rel="up" title="Top">
- <link href="Gcov.html#Gcov" rel="next" title="Gcov">
- <link href="Forwarding-hook.html#Forwarding-hook" rel="prev" title="Forwarding hook">
- <style type="text/css">
- <!--
- a.summary-letter {text-decoration: none}
- blockquote.indentedblock {margin-right: 0em}
- blockquote.smallindentedblock {margin-right: 0em; font-size: smaller}
- blockquote.smallquotation {font-size: smaller}
- div.display {margin-left: 3.2em}
- div.example {margin-left: 3.2em}
- div.lisp {margin-left: 3.2em}
- div.smalldisplay {margin-left: 3.2em}
- div.smallexample {margin-left: 3.2em}
- div.smalllisp {margin-left: 3.2em}
- kbd {font-style: oblique}
- pre.display {font-family: inherit}
- pre.format {font-family: inherit}
- pre.menu-comment {font-family: serif}
- pre.menu-preformatted {font-family: serif}
- pre.smalldisplay {font-family: inherit; font-size: smaller}
- pre.smallexample {font-size: smaller}
- pre.smallformat {font-family: inherit; font-size: smaller}
- pre.smalllisp {font-size: smaller}
- span.nolinebreak {white-space: nowrap}
- span.roman {font-family: initial; font-weight: normal}
- span.sansserif {font-family: sans-serif; font-weight: normal}
- ul.no-bullet {list-style: none}
- -->
- </style>
-
-
- </head>
-
- <body lang="en">
- <a name="Compatibility"></a>
- <div class="header">
- <p>
- Next: <a href="Gcov.html#Gcov" accesskey="n" rel="next">Gcov</a>, Previous: <a href="Objective_002dC.html#Objective_002dC" accesskey="p" rel="prev">Objective-C</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
- </div>
- <hr>
- <a name="Binary-Compatibility"></a>
- <h2 class="chapter">9 Binary Compatibility</h2>
- <a name="index-binary-compatibility"></a>
- <a name="index-ABI"></a>
- <a name="index-application-binary-interface"></a>
-
- <p>Binary compatibility encompasses several related concepts:
- </p>
- <dl compact="compact">
- <dt><em>application binary interface (ABI)</em></dt>
- <dd><p>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.
- </p>
- </dd>
- <dt><em>ABI conformance</em></dt>
- <dd><p>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.
- </p>
- </dd>
- <dt><em>calling conventions</em></dt>
- <dd><p>Calling conventions are a subset of an ABI that specify of how arguments
- are passed and function results are returned.
- </p>
- </dd>
- <dt><em>interoperability</em></dt>
- <dd><p>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.
- </p>
- </dd>
- <dt><em>intercallability</em></dt>
- <dd><p>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.
- </p>
- </dd>
- <dt><em>implementation-defined features</em></dt>
- <dd><p>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.
- </p>
- </dd>
- <dt><em>compatibility</em></dt>
- <dd><p>Conformance to the same ABI and the same behavior of implementation-defined
- features are both relevant for compatibility.
- </p></dd>
- </dl>
-
- <p>The application binary interface implemented by a C or C++ compiler
- affects code generation and runtime support for:
- </p>
- <ul>
- <li> size and alignment of data types
- </li><li> layout of structured types
- </li><li> calling conventions
- </li><li> register usage conventions
- </li><li> interfaces for runtime arithmetic support
- </li><li> object file formats
- </li></ul>
-
- <p>In addition, the application binary interface implemented by a C++ compiler
- affects code generation and runtime support for:
- </p><ul>
- <li> name mangling
- </li><li> exception handling
- </li><li> invoking constructors and destructors
- </li><li> layout, alignment, and padding of classes
- </li><li> layout and alignment of virtual tables
- </li></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>
- <p>Most platforms have a well-defined ABI that covers C code, but ABIs
- that cover C++ functionality are not yet common.
- </p>
- <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>-Wabi</samp> switch warns when G++ generates code that is
- probably not compatible with the C++ ABI.
- </p>
- <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>
- <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>-v</samp> option.
- With default configuration options for G++ 3.3 the compile line for a
- different C++ compiler needs to include
- </p>
- <div class="smallexample">
- <pre class="smallexample"> -I<var>gcc_install_directory</var>/include/c++/3.3
- </pre></div>
-
- <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>
- <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 <code>g++</code> driver, for example, tells the linker where
- to find GCC’s C++ library (<samp>libstdc++</samp>) plus the other libraries
- and startup files it needs, in the proper order.
- </p>
- <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 <code>g++</code> 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>-nostdlib</samp>,
- <samp>-nostartfiles</samp>, and <samp>-nodefaultlibs</samp>.
- </p>
-
- <hr>
- <div class="header">
- <p>
- Next: <a href="Gcov.html#Gcov" accesskey="n" rel="next">Gcov</a>, Previous: <a href="Objective_002dC.html#Objective_002dC" accesskey="p" rel="prev">Objective-C</a>, Up: <a href="index.html#Top" accesskey="u" rel="up">Top</a> [<a href="index.html#SEC_Contents" title="Table of contents" rel="contents">Contents</a>][<a href="Option-Index.html#Option-Index" title="Index" rel="index">Index</a>]</p>
- </div>
-
-
-
- </body>
- </html>
|