Date: Fri, 21 Feb 2020 14:36:37 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221123637.GT29554@kib.kiev.ua> In-Reply-To: <20200221120325.GA86511@bec.de> References: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com> <20200220141655.GP29554@kib.kiev.ua> <CAGsORuBVGVbjqW-_psM9ze1N-J9emuceUiLA=N11nd%2BFZWxzQA@mail.gmail.com> <20200221120325.GA86511@bec.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200221123637.GT29554>