How much libc++ ABI changes FreeBSD can consume?

Joerg Sonnenberger joerg at bec.de
Fri Feb 21 12:03:30 UTC 2020


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.

Joerg


More information about the freebsd-hackers mailing list