Date: Fri, 21 Feb 2020 13:58:46 +0100 From: Joerg Sonnenberger <joerg@bec.de> To: freebsd-hackers@freebsd.org Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221125846.GA88921@bec.de> In-Reply-To: <20200221123637.GT29554@kib.kiev.ua> References: <CAGsORuC7HVCCGRRLL92OQgLDAjTVRGmrMLsH=9Pn%2BsKgSKoQhg@mail.gmail.com> <20200220141655.GP29554@kib.kiev.ua> <CAGsORuBVGVbjqW-_psM9ze1N-J9emuceUiLA=N11nd%2BFZWxzQA@mail.gmail.com> <20200221120325.GA86511@bec.de> <20200221123637.GT29554@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Feb 21, 2020 at 02:36:37PM +0200, Konstantin Belousov wrote: > 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. Take a look at all the pain libstdc++ had with its new string implementation. Symbol versioning is fine as long as the ABI doesn't extend beyond the boundaries of the depending DSOs. But if you want to change e.g. std::string, all libraries to be mixed need to version any interface containing it and that is effectively as much trouble as just doing the DSO bump. Joerg
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20200221125846.GA88921>