Thoughts on managing C++ ABI breaks

Mike Hearn mike at navi.cx
Sat Jul 31 13:43:51 UTC 2004


Hi guys,

This is a proposal for a way to handle backwards compatibility in the
face of continuing C++ compiler ABI breaks. Rationale: 


- The GCC team have an explicit policy of preferring standards compliance
to ABI stability. I think there is no 100% perfect test suite for this
standard, and even if there was, it's unlikely that such a complicated
document is never open to interpretation. Likewise the C++ spec itself
evolves with time. 

Consequently, it's possible (probable?) that we will be dealing with ABI
breaks into the medium term future. These need to be managed.


- It is desireable to have binary compatibility and to manage interface
breaks. This is what ELF soname versioning is all about, but in the face
of compiler breaks as opposed to library breaks, soname versioning is not
enough. A library libqt.so.3 compiled with one compiler may not export the
same interface as libqt.so.3 compiled with another, yet the user may wish
to run binaries compiled with the gcc 3.3 ABI on a 3.4 compiled system.


One of my assumptions is that the C++ standard library is parallel
installable and has a different soname for each ABI. From what I've read
about g++ ABI policy this assumption seems to be correct, please let me
know if it is not.

The proposal is to modify the dynamic linker so that when a
library which depends on a symbol version of CXXABI_X.Y is loaded, each
element in the library search path is tested once with $dirname/cxxabi-X.Y
and once with $dirname. So, if you have a version of Qt compiled with abi
1.2 (gcc 3.2,3.3), that can be placed in /usr/lib/cxxabi-1.2/libqt.so.3
and then the version compiled with the "native" ABI can be placed in
/usr/lib as per normal.

A similar technique has been used before with the LD_ASSUME_KERNEL
environment variable switching between /lib, /lib/i686, /lib/tls and so
on. This mechanism would be similar, except triggered by the CXXABI symbol
version rather than an environment variable.

This allows C++ binaries built for older versions of the system to operate
correctly on newer systems when the right compat-* packages are installed.

I propose this here as there are a good set of distro, glibc
and gcc developers working for Red Hat, so it seemed like a good place to
find people to shoot it down :)

What are peoples thoughts on this mechanism? Using CXXABI_ is somewhat
inelegant but this has the advantage that it works with the toolchains
already deployed.

thanks -mike





More information about the fedora-devel-list mailing list