Plan for dealing with libstdc++ ABI break

[jfirebaugh]

The libstdc++ ABI break poses a challenge for mason (#155) as we see more use of gcc/libstdc++ >= 5.1.

This affects any library that exports a symbol that uses an ABI-tagged type -- e.g. a function returning std::string.

As I understand it, if mason wants to package libraries of this type, then the choices are:

• Require downstream consumers to compile everything with libstdc++ < 5.1, or with -D_GLIBCXX_USE_CXX11_ABI=0. This is the status quo.
• Require downstream consumers to compile everything with libstdc++ >= 5.1 and -D_GLIBCXX_USE_CXX11_ABI=1. This is the "force everyone to upgrade" option.
• Provide dual-ABI symbols in each library itself. This is the "provide backward compatibility by copying what libstdc++ itself does" option. It's probably infeasible due to the amount of work on 3rd party libraries that would be required.
• Start embedding the ABI setting in the mason platform slug (e.g. linux-x86-cxx03abi vs linux-x86-cxx11abi). Build all libraries for both ABIs.
• Start embedding the ABI setting in the mason package slug (e.g. gtest-1.7.0-cxx03abi vs gtest-1.7.0-cxx11abi). Build all libraries that export ABI-tagged symbols for both ABIs.

I currently favor the last option but would like to hear other opinions.

cc @springmeyer @tmpsantos

---

Dropping a link to https://llvm.org/bugs/show_bug.cgi?id=23529 here as well. I don't fully understand the implications there, but it sounds like we may be stuck using GLIBCXX_USE_CXX11_ABI=0 if compiling with clang.

[jfirebaugh]

• Start embedding the ABI setting in the mason package slug (e.g. gtest-1.7.0-cxx03abi vs gtest-1.7.0-cxx11abi). Build all libraries that export ABI-tagged symbols for both ABIs.

As a variation on this, another option would be to start migrating new versions of packages to cxx11abi, and include the ABI specifier in the slug only for the legacy ABI -- e.g. gtest-1.8.0-cxx03abi vs gtest-1.8.0. This would set us up for a return to ABI-less slugs once everything has been migrated to libstdc++ >= 5.1.

[tmpsantos]

My suggestion is to only make binaries for gcc/libstdc++ >= 5.1. If the system doesn't support it, we will force build the package from the sources. 5.1+ will be the default on Ubuntu 16.04 LTS.

Currently the only packages that are causing trouble are gtest and geojsonvt that are small and not big of a deal in terms of compilation time (and in a dev environment you only build them once anyway). This is mostly a problem for build bots that do a clean build everytime.

_GLIBCXX_USE_CXX11_ABI=0 no longer works. I've been using it for a while but even with it I'm getting a link error on geojsonvt with a binary built for cxx03abi in a single symbol. That is what made me to remove the binaries and thus force compilation from the sources.

Start embedding the ABI setting in the mason package slug (e.g. gtest-1.7.0-cxx03abi vs gtest-1.7.0-cxx11abi). Build all libraries that export ABI-tagged symbols for both ABIs.

I guess my suggestion is compatible with this one if you don't build gtest-1.7.0-cxx03abi. I'm fine building it, but it will be hard in the future to setup an environment just for that.

[springmeyer]

Start embedding the ABI setting in the mason package slug (e.g. gtest-1.7.0-cxx03abi vs gtest-1.7.0-cxx11abi). Build all libraries that export ABI-tagged symbols for both ABIs.

I'm supportive of this idea most. @jfirebaugh you did not say whether or not the names of cxx03abi or cxx11abi would be built into mason. But I'm going to ruminate here assuming that is what you are proposing... I think we should consider whether the modifier (in this case cxx03abi or cxx11abi) should be flexible and not chosen by mason but rather by the package. I'm not 100% sure on this but the thinking is...

• ABI incompatibilities may be due to bugs/differences between compilers (of the past or future) and not just standard library version or modifiers to standard library behavior (like _GLIBCXX_USE_CXX11_ABI). I can imagine therefore having, for example:
  • geojsonvt-4.1.2 (best default, could target latest ubuntu LTS)
  • geojsonvt-4.1.2-clang-35 (creates binaries incompatible with gcc 5 but also do not require upgrading libstdc++ on ubuntu trusty)
  • geojsonvt-4.1.2-clang-38 (creates binaries compatible with gcc 5 but those binaries also trigger the need to upgrade libstdc++ on ubuntu trusty via the ubuntu-toolchain-r ppa)
  • geojsonvt-4.1.2-gcc5-cxx03abi (as per @jfirebaugh example above)
  • geojsonvt-4.1.2-gcc5-cxx11abi (as per @jfirebaugh example above)
  • geojsonvt-4.1.2-march-native (non-portable, cpu specific compiler options enabled)

This flexibility would also be useful for making it easy to try various build options to isolate the cause of ABI incompatibility + then stick with it without having to change mason behavior.

[springmeyer]

I think we should consider whether the modifier (in this case cxx03abi or cxx11abi) should be flexible and not chosen by mason but rather by the package

Ah, sorry I should have seen and digested #162 first. As far as I can tell #162 is just as I would hope: it is not building the suffix names into mason but allowing them to be arbitrary per the package, which I think is the flexibility we need. 👍 Apologies for not seeing that first before commenting.

[springmeyer]

_GLIBCXX_USE_CXX11_ABI=0 no longer works.

Followup on this is that it does work: just make sure to set -D_GLIBCXX_USE_CXX11_ABI=0 in the flags for the library that is building and linking against a given mason package, as well as the custom mason package. Otherwise you might be at the mercy of difference g++ compilers having different defaults for this value - best to be consistently explicit.