Date: Thu, 20 Feb 2020 16:16:55 +0200 From: Konstantin Belousov <kib@freebsd.org> To: Zhihao Yuan <lichray@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, dim@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200220141655.GP29554@kib.kiev.ua> In-Reply-To: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com> References: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200220141655.GP29554>