How much libc++ ABI changes FreeBSD can consume?

Joerg Sonnenberger joerg at bec.de
Fri Feb 21 14:30:04 UTC 2020


On Fri, Feb 21, 2020 at 03:19:39PM +0200, Konstantin Belousov wrote:
> On Fri, Feb 21, 2020 at 01:58:46PM +0100, Joerg Sonnenberger wrote:
> > Take a look at all the pain libstdc++ had with its new string
> > implementation. Symbol versioning is fine as long as the ABI doesn't
> > extend beyond the boundaries of the depending DSOs. But if you want to
> > change e.g. std::string, all libraries to be mixed need to version any
> > interface containing it and that is effectively as much trouble as just
> > doing the DSO bump.
> 
> Right, as I understand, inline namespaces were the reaction to this and
> similar issues.  With new namespace, std::string methods would get different
> mangled name.
> 
> I am not claiming that either approach (or its combination) cover
> everything, but the situation should be not that dim. E.g., after ino64
> changes, I am aware of only one serious breakage when running binaries
> built for older struct stat, on newer system, and this comes from
> Firefox doing dlsym("stat").

The difference is that ino_t and transitively stat are passed around
rarely between libraries. This is completely different from std::string,
which is passed around a lot between C++ libraries. As such, any such
interface needs to be versioned. This gets worse if it is a member of a
public class, because then every use of that class has to be versioned
as well.

Joerg


More information about the freebsd-hackers mailing list