Date: Fri, 21 Feb 2020 14:35:45 +0200 From: Konstantin Belousov <kib@freebsd.org> To: Zhihao Yuan <lichray@gmail.com> Cc: FreeBSD Hackers <freebsd-hackers@freebsd.org>, Dimitry Andric <dim@freebsd.org> Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221123545.GS29554@kib.kiev.ua> In-Reply-To: <CAGsORuBVGVbjqW-_psM9ze1N-J9emuceUiLA=N11nd%2BFZWxzQA@mail.gmail.com> References: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com> <20200220141655.GP29554@kib.kiev.ua> <CAGsORuBVGVbjqW-_psM9ze1N-J9emuceUiLA=N11nd%2BFZWxzQA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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. We do not deny the possibility of upgrade outright, but decision to do so cannot be taken lightly. Upgrade should provide a large benefit to upgrade (or very large penalty to not upgrade). If it combines with additional measures that ensure more stable ABI in future, like applying symbol versioning, this alone might be considered a large enough benefit. > And we hope/encourage libc++ to > version symbols like what libstdc++ does, > correct? Yes, but we expect the upstream to care about ABI even more then.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200221123545.GS29554>