How much libc++ ABI changes FreeBSD can consume?

[Konstantin Belousov]

On Wed, Feb 19, 2020 at 10:27:57PM -0600, Zhihao Yuan wrote:
> Hi,
> 
> I'm sending this email because
> 
>  a. FreeBSD has been stuck on libc++ V1 ABI
>     long enough.  I would like to learn some details.
>  b. There is an ongoing discussion in the C++
>     standards committee talking about whether
>     the standard library should break ABI on a
>     regular basis.
> 
This is only part of the answers to your questions, Dmitry (Cc:ed) would
provide more info later.

> Here are my questions:
> 
>  1. Is FreeBSD waiting for libc++ V2 ABI to freeze?
>     If so, will FreeBSD switch to V2 ABI afterwards?
See later responses.

>  2. The pkgs are tagged with __FreeBSD_version,
>     is that enough to allow libc++ ABI to change
>     at every FreeBSD (major) release?
No.  This mechanism has nothing to do with userspace ABI.

>  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.

If applying the symver policy to the library, we expect that it would
prevent any dso version bumps in the future. Normally we bump dso
version for introducing the symver, which is technically not strictly
necessary but appeared to solve some corner cases.