12

My goal is to use gcc 7.2 (and clang 6) on Centos 7 to build executables compatible with Centos 7 targets without devtoolset installed but * using the newer C++ ABI *.

The newer ABI fixed a couple of deficiencies in the lib that weren't able to be fixed without an ABI change. E.g list::size O(1) Vs O(n), no COW for strings.

I speculated on an answer as to why this might not be possible in the following question. -D_GLIBCXX_USE_CXX11_ABI=1 ineffective for devtoolset-7 on CentOS 7

Paul
  • 161
  • 1
  • 6
  • 1
    I've never had a problem building with devtoolset-7 (using `-std=c++14`) and running on other boxes with no toolset. what is the problem? – Brad Allred Mar 21 '18 at 04:31
  • With _GLIBCXX_USE_CXX11_ABI=0 devtoolset is fine using just the old stdlib plus an incremental not shared lib for newer API features. But using the new ABI (=1), I'm suggesting that is no longer the case as old stdlib is binary incompatible with the newer lib. The original question suggested that setting the new behaviour didn't work and was ignored. – Paul Mar 21 '18 at 04:51
  • @Praetorian, your comments are quite misleading. By default every `libstdc++.so` is built with support for **both** `_GLIBCXX_USE_CXX11_ABI=1` and `_GLIBCXX_USE_CXX11_ABI=0` so is already compatible with the system libstdc++.so, and you **do not** need to set that macro when building libstdc++ (nor GCC). The problem really is specific to devtoolset and its mixed static/dynamic linkage model. – Jonathan Wakely Oct 02 '18 at 15:22
  • @JonathanWakely Thank you for clarifying; I'm really happy you came across this question and we have an authoritative answer now. I've deleted my earlier comments. – Praetorian Oct 02 '18 at 15:51

1 Answers1

8

This seems like a duplicate of the question you linked to, I don't see any reason to keep both open.

Can I use the new C++ 11 ABI with devtoolset-7 on Centos/RHEL?

No. The cxx11 ABI affects a number of things internal to libstdc++.so (specifically, locale facets) which cannot be supported by the devtoolset mixed linkage model. The relevant functions that initialize locales are already present in the system libstdc++.so and can't be replaced by the devtoolset's libstdc++_nonshared.a. Because of that (and to avoid other potential ABI mismatches that we don't want to affect RHEL/CentOS users) we disable the new ABI in devtoolset (as correctly stated in the answer to the other question).

If you really need the new cxx11 ABI you'll need to build your own GCC 7 that uses normal dynamic linking to its own libstdc++.so (rather than the mixed linkage model used by devtoolset) and then ensure that new libstdc++.so gets used at runtime (see Finding Dynamic or Shared Libraries in the manual).

Jonathan Wakely
  • 166,810
  • 27
  • 341
  • 521
  • Thanks @Jonathan Wakely! I would need some clarification, please. If I understood well, the only thing to worry about not using the new `cxx11`ABI is having `list::size()` O(n) instead of O(1), COW for strings and the locale facets you mentioned. Apart from this, would a binary compiled on let's say CentOS/RHEL 6.0 with devtoolset-7 and `-std=gnu++14` run in the rest of 6.X and 7.X correctly? I only need to worry about performance if using `list::size()` and so on, right? – rboc Oct 19 '18 at 00:16
  • 1
    You can compile and test the D_GLIBCXX_USE_CXX11_ABI=1 compiler on Centos 7/RHEL 7 using this ansible-role https://github.com/dockpack/compile_gcc. On Centos stream 8 and RHEL8 there's no need for this. – bbaassssiiee Nov 28 '22 at 21:49