C++ binary compatibility between different versions of gcc

Jonathan Wakely jwakely.gcc@gmail.com
Mon Mar 4 18:01:00 GMT 2013


On 4 March 2013 16:48,  <Heiko.Papenfuss@uniserv.com> wrote:
> Hi,
>
> after reading a whole lot of stuff about binary compatibility of gcc and searching the gcc-help archive, too, I am still somewhat confused regarding the C++ binary compatibility between different versions of gcc.
>
> The questions I am trying to answer are these:
>
> 1.) My impression is that the whole question of binary compatibility boils down to or is rather a synonym for C++ ABI compatibility (or stability if narrowed down to the question of the binary compatibility of binaries produced by different versions of gcc). Is this correct?

Yes.

There are two parts to that: the platform ABI that the compiler uses
and the ABI of any libraries you use, see
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C++
for more details.  For example, you could add a virtual function to a
library type, which would change the library's ABI even if compiled
with same compiler release.

> 2.) [1] states that starting with GCC 3.2, there is a default C++ ABI (the vendor-neutral C++ ABI) that GCC tries to adhere to. However, there is not a hint of which versions did or did not, or with which versions of GCC an incompatible change of the ABI has happened.

The manual for each version tells you the default value for -fabi-version

> [3] indicates then that "It's pretty easy to see when the ABI has changed because we bump the major release number in the soname." of libstdc++.so and as one can figure out looking at [2], this has not happened since libstdc++.so.6.0.0, which came with GCC 3.4.0. From that, I am willing to draw the conclusion that the compiler ABI has been stable since then. Is this correct and is it therefore save to say that a library compiled with GCC 3.4.x can be linked against (dynamically or statically) with GCC 4.y.z, if we assume that all ABI-affecting compiler flags have been the same (esp. -fabi-version=2)?

Yes.  (Technically if the object files were compiled with
ABI-compatible GCC versions then what matters at link-time is not
which version of GCC you use to do the link, it's which version of
libstdc++.so you link against, but that is usually determined by the
version of GCC used, unless you specifically force GCC to link to a
different libstdc++.so)

> Does the reverse hold, too?

What is the reverse case?  If you are asking whether a library
compiled with GCC 4.x can be linked against using GCC 3.4 the answer
is no, libstdc++.so ABI compatibility only goes backwards, not
forwards.

If any object in your program (or any object in any library it links
to) was compiled with GCC version X then at run-time the program must
be linked to the libstdc++.so from GCC X or later.  You cannot compile
with GCC X then use libstdc++.so from GCC X-1 at run-time.



More information about the Gcc-help mailing list