Date: Fri, 21 Feb 2020 15:29:58 +0100 From: Joerg Sonnenberger <joerg@bec.de> To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221142958.GA69281@bec.de> In-Reply-To: <20200221131939.GV29554@kib.kiev.ua> References: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com> <20200220141655.GP29554@kib.kiev.ua> <CAGsORuBVGVbjqW-_psM9ze1N-J9emuceUiLA=N11nd%2BFZWxzQA@mail.gmail.com> <20200221120325.GA86511@bec.de> <20200221123637.GT29554@kib.kiev.ua> <20200221125846.GA88921@bec.de> <20200221131939.GV29554@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200221142958.GA69281>