GCC5 and the C++11 ABI

The GNU C++ team works hard to avoid breaking ABI compatibility between releases, including between different -std= modes. But some new complexity requirements in the C++11 standard require ABI changes to several standard library classes to satisfy, most notably to std::basic_string and std::list. And since std::basic_string is used widely, much of the standard library is affected.

Many users routinely rebuild all their code when they change compilers; such users will be unaffected by this change. Code built with an earlier compiler will also continue to work with the new libstdc++, which provides both old and new ABIs.

Users that depend on third-party libraries or plugin interfaces that still use the old ABI can build their code with -D_GLIBCXX_USE_CXX11_ABI=0 and everything should work fine. In most cases, it will be obvious when this flag is needed because of errors from the linker complaining about unresolved symbols involving "__cxx11".

Providers of such libraries or interfaces need to consider whether they want to provide ABI coexistence, like libstdc++ does, or require their users to rebuild.  If they want to provide coexistence, they need to understand how to handle the change.

The last time G++ went through an ABI change, back in the 3.x period, we changed the soname of libstdc++, which was widely regarded as a mistake. Changing the soname caused a lot of pain but is not sufficient to deal with changes in symbol ABIs: if you load multiple shared objects that depend on different versions of the library, you can still get clashes between different versions of the same symbol.

So the plan for this ABI change has been to leave the soname (and the existing binary interface) alone, and express the new ABI using different mangled names.

C++11 introduced inline namespaces, which are useful for changing the mangled name of a type or declaration without affecting its users. But inline namespaces only deal with ABI changes that are visible in the mangled name; for other ABI changes, such as changes to return type or non-static data members, we need to do something else.

So we've introduced the notion of ABI "tags", to correspond to particular changes in the ABI of a type, function, or variable that would not otherwise be reflected in the mangled name. ABI tags become part of the mangled name, and thereby avoid the problem of two conflicting definitions of the same symbol. Tags are expressed via attribute abi_tag, which can be applied to an inline namespace, or directly to a declaration. So to allow the new ABI to coexist with the old ABI, a library such as libstdc++ needs to ensure that all the declarations with modified ABI are tagged appropriately.

#ifdef ABI_CHANGE
inline namespace abi2 __attribute ((abi_tag)) {
  class MyType { ... };
  MyType fn();
}
#endif

Since C++ allows classes to be declared as incomplete before they are defined, we can't just automatically propagate tags from, e.g., base to derived class. The derived class needs to be explicitly tagged as well. To help with this, the compiler provides the -Wabi-tag flag, which warns about any declarations which involve a tagged type but don't have that tag themselves.

// warning: Derived does not have the abi2 tag
struct Derived: MyType { ... };

It is recommended to use inline namespaces for tags when possible, but that obviously won't work for non-namespace-scope declarations such as member functions.  If there is an ABI change to a member function that is not reflected in the mangled name, then you can apply a tag to it directly.  For instance, the return type of complex::real changed in C++11:

#if __cplusplus >= 201103L
      __attribute ((abi_tag ("cxx11")))
      constexpr _Tp real() const { return _M_real; }
#else
      _Tp& real() { return _M_real; }
#endif

The libabigail (https://sourceware.org/libabigail/) tools are also useful for testing whether there are any ABI changes in existing symbols between versions of your library.

Again, only providers of libraries and the like need to think about these complexities, and then only if they want to provide backward compatibility.  Users just need to make sure that they are building with the ABI used by the libraries that they depend on.

Red Hat Enterprise Linux 7 ships with GCC 4. You can easily install the latest stable version of GCC using yum. As of May 2018, GCC 7.3 was shipped as part of Red Hat Developer Toolset (DTS).