_Glibcxx_Use_Cxx11_Abi, Gcc 4.8 and Abi Compatibility

_GLIBCXX_USE_CXX11_ABI, GCC 4.8 and ABI compatibility

It's possible to use the C++11 ABI with gcc 4.8.2, but it's a dangerous hack; you would be far better off if at all possible to ask your vendors to ship libraries compiled with the C++03 ABI (-D_GLIBCXX_USE_CXX11_ABI=0) or to upgrade to GCC 5 or above.

You would need to download and install gcc 5 so that you can use its libstdc++ headers and libraries, then direct gcc 4.8 to use those in preference to its own. In addition, because gcc 4.8 is missing some intrinsics required by the libstdc++ shipped with gcc 5, you would need to hack out their usage.

For example, to compile a simple single-file application that includes <string>:

/usr/local/gcc-4.8.2/bin/g++ \
   -std=c++11 \
   -D_GLIBCXX_USE_CXX11_ABI=1 \
   -D'__is_trivially_copyable(...)=0' \
   -D'__is_trivially_constructible(...)=0' \
   -D'__is_trivially_assignable(...)=0' \
   -nostdinc++ \
   -isystem /usr/local/gcc-5.4.0/include/c++/5.4.0/ \
   -isystem /usr/local/gcc-5.4.0/include/c++/5.4.0/x86_64-unknown-linux-gnu \
   -L /usr/local/gcc-5.4.0/lib64
   a.cpp

This is dangerous because the gcc 5.4 libstdc++ is not designed to work with gcc 4.8, and redefining the intrinsics used (__is_trivially_copyable etc.) could change the layout of structures or otherwise cause binary incompatibility between your programs and the vendor's libraries.

In order to run the resulting executable, you would also need to ensure that the dynamic linker finds a compatible libstdc++, for example by adding /usr/local/gcc-5.4.0/lib64 to /etc/ld.so.conf, or using -Wl,-rpath /usr/local/gcc-5.4.0/lib64.

How to Compile boost with GCC 5 using old ABI?

To my knowledge, there are no prebuilt Boost packages for the old ABI in the official Kubuntu repositories, so you will have to build Boost yourself. The building process is documented here.

Make sure you're building the same Boost version that was used when your library was built. If there were any Boost configuration macros defined, you will also have to define them the similar way. Otherwise you may encounter ABI incompatibilities between the library and Boost you've built.

In order to switch libstdc++ to the old ABI you will also have to define _GLIBCXX_USE_CXX11_ABI to 0, as described here. For example:

b2 -j8 variant=release define=_GLIBCXX_USE_CXX11_ABI=0 stage

You will also need to define the macro when you build your own code that uses Boost and the library.

The define property, along with many others, is documented here.

Undocumented ABI changes of std::function between GCC-4 and GCC-5/6/7/8/9, how to make a .so working with devtoolset-4/6/7/8/9?

So I can not write a .so using std::function compiled by gcc4 and used by gcc5/6/7/8.

Correct. Neither Red Hat nor the GCC project has ever claimed that's possible, quite the opposite. C++11 support in GCC 4.x was incomplete and unstable, and subject to ABI changes and API changes. What you're trying to do was never supported.

I've explained this in more detail at https://stackoverflow.com/a/49119902/981959

The Developer Toolset documentation covers it too (emphasis mine):

"A compiler in C++11 or C++14 mode is only guaranteed to be compatible with another compiler in C++11 or C++14 mode if they are from the same release series (for example from Red Hat Developer Toolset 6.x).
...

"Using the C++14 language version is supported in Red Hat Developer Toolset when all C++ objects compiled with the respective flag have been built using Red Hat Developer Toolset 6 or later. Objects compiled by the system GCC in its default mode of C++98 are also compatible, but objects compiled with the system GCC in C++11 or C++14 mode are not compatible."

There is no macro like _GLIBCXX_USE_CXX11_ABI can control the behavior.

We do not provide macros to control things that are unsupported and cannot work.

If you want to use C++11 with a mix of GCC versions you need to use a release that has stable, non-experimental support for C++11. So not GCC 4.x.

How can I deploy a C++11 program (with dependencies) on CentOS 6, whose GCC is C++03?

Actually, you can distribute a program compiled with a newer g++ compiler on a vanilla CentOS 6 platform. There are several ways to do this: The easiest is to use the DevToolset 3, which will give you g++ 4.9.2 (the dev toolset 2 will give you gcc 4.8.2). Then, just compile your application with this g++. When distributing your software, you need to make sure to also ship the libstdc++.so that is being shipped with g++ 4.9. Either set the LD_LIBRARY_PATH so it gets picked up on startup, or set the RPATH to tell your executable where to look first for libraries.

Essentially, you can do this also with newer compilers, but then you first need to compile the compiler itself. If you don't want to compile a compiler first, go with a respective dev toolset and you should be fine.

Yes, you can also try to statically link libstdc++.a. Search for the option -static-libstdc++:

When the g++ program is used to link a C++ program, it normally automatically links against libstdc++. If libstdc++ is available as a shared library, and the -static option is not used, then this links against the shared version of libstdc++. That is normally fine. However, it is sometimes useful to freeze the version of libstdc++ used by the program without going all the way to a fully static link. The -static-libstdc++ option directs the g++ driver to link libstdc++ statically, without necessarily linking other libraries statically.

But if you statically link, you will not get any security updates etc. Granted, you will not get the updates, if you ship libstdc++.so on your own as well, but incremental updates maybe easier.

And with respect to running your application: The rule of thumb is: Compile on the oldest platform you need to support, then your binaries (with self-shipped libstdc++ and other required libs) will likely work also on newer versions. That is, if you compile on CentoOS 6, and it works, then you can expect it to also work on CentOS 7. On a related subject, this is exactly the reason why for instance AppImage and related solutions recommend to build on an old system.

---

Related Topics