Re: libstdc++ and dual ABI

[christos%astron.com@localhost (Christos Zoulas)]

In article <20170928131053.GA4777%britannica.bec.de@localhost>,
Joerg Sonnenberger  <joerg%bec.de@localhost> wrote:
>Hello everyone,
>during the developer summit, I was made aware that we got the fancy dual
>ABI for libstdc++ with the GCC 5 import. I thought that $#%#$% was
>disabled from the start, but alas, it isn't.
>
>What does dual ABI mean? Long story. std::string in libstdc++ had
>a performance "feature" for ages where it avoided string copying by
>using reference counting. This has a number of implications, one of them
>is that in-place modifications will invalidate iterators. Since this
>makes the behavior highly unpredictable especially in multithreaded
>programs, C++11 forbids it. Since changing central parts of std::string
>requires an ABI change, GCC decided to provide both old and new
>interface in the same code and introduce a fancy hack in the name
>mangler. Inline namespaces as used by libc++ wouldn't allow both ABIs to
>coexist, since functions using std::string only in the return type
>wouldn't be mangled different as that case is not allowed in C++.
>
>Why is this bad? It means that if libfoo is compiled with -std=c++11 and
>foobar is compiled with -std=c++03, they can't be linked together and
>vice versa. While many libraries are starting to adopt C++11 features,
>not everyone does. The dual ABI makes interaction between the standards
>*worse*, just to avoid a major bump.
>
>What should we do? I want to take the time before the 8.0 release and
>switch GCC over to always use the new ABI. This means recompiling all
>C++ code, but I consider it the lesser evil of having to deal with the
>fallout in pkgsrc for years to come.

Please go for it!

christos