How much libc++ ABI changes FreeBSD can consume?
Konstantin Belousov
kostikbel at gmail.com
Fri Feb 21 13:19:48 UTC 2020
On Fri, Feb 21, 2020 at 01:58:46PM +0100, Joerg Sonnenberger wrote:
> On Fri, Feb 21, 2020 at 02:36:37PM +0200, Konstantin Belousov wrote:
> > On Fri, Feb 21, 2020 at 01:03:25PM +0100, Joerg Sonnenberger wrote:
> > > On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote:
> > > > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov <kib at freebsd.org> wrote:
> > > >
> > > > > > 3. Is MFC required for libc++ updates? If so, how
> > > > > > does that affect ABI changes?
> > > > > It is highly desirable to get libc++ synced between head and all actively
> > > > > supported stable versions.
> > > > >
> > > > > > 4. Is there any desire to make C++ ABI breakage
> > > > > > smoother by ultilzing mechanisms such as
> > > > > > Symbol.map?
> > > > > Yes. More expanded answer below.
> > > > >
> > > > > Right now any libc++ ABI breakage requires dso version bump. We try hard
> > > > > to avoid that because it trivially leads to a situation when multiple
> > > > > libc++'s are loaded into same process, unless everything is recompiled
> > > > > against same lib. In other words, bumping version for such fundamental
> > > > > library is too troublesome.
> > > > >
> > > > > Symver provides a solution for gradual ABI changes, but by policy
> > > > > we never provide symbol versioning for third-party libraries unless
> > > > > upstream maintains the versioning. The reason is that we cannot enforce
> > > > > upstream ABI policy, which would make versioning broken by updates and
> > > > > then pointless.
> > > > >
> > > > > So for instance libstdc++.so from gcc is versioned, while ncurses are not.
> > > > >
> > > >
> > > > To summarize what I heard, even if libc++
> > > > stabilizes V2 ABI, we do not want to do an
> > > > "ABI break since release 1X" thing. If we
> > > > really upgrade, we break all stable versions.
> > > > And we hope/encourage libc++ to
> > > > version symbols like what libstdc++ does,
> > > > correct?
> > >
> > > Symbol versioning helps really little for this kind of ABI breaks. It
> > > still ends up effectively being a flag day as libraries build before and
> > > after don't interact that well with each other.
> > It helps some, and from my undertanding, symver + properly used inline
> > namespaces cover much, if not everything.
>
> 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").
More information about the freebsd-hackers
mailing list