From owner-freebsd-hackers@freebsd.org Fri Feb 21 12:35:54 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A294C25C88F for ; Fri, 21 Feb 2020 12:35:54 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 48P9t14ZDzz3Mfd; Fri, 21 Feb 2020 12:35:53 +0000 (UTC) (envelope-from kib@freebsd.org) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.15.2/8.15.2) with ESMTPS id 01LCZjbD010708 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 21 Feb 2020 14:35:48 +0200 (EET) (envelope-from kib@freebsd.org) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 01LCZjbD010708 Received: (from kostik@localhost) by tom.home (8.15.2/8.15.2/Submit) id 01LCZjp0010707; Fri, 21 Feb 2020 14:35:45 +0200 (EET) (envelope-from kib@freebsd.org) X-Authentication-Warning: tom.home: kostik set sender to kib@freebsd.org using -f Date: Fri, 21 Feb 2020 14:35:45 +0200 From: Konstantin Belousov To: Zhihao Yuan Cc: FreeBSD Hackers , Dimitry Andric Subject: Re: How much libc++ ABI changes FreeBSD can consume? Message-ID: <20200221123545.GS29554@kib.kiev.ua> References: <20200220141655.GP29554@kib.kiev.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on tom.home X-Rspamd-Queue-Id: 48P9t14ZDzz3Mfd X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-1.74 / 15.00]; local_wl_from(0.00)[freebsd.org]; NEURAL_HAM_MEDIUM(-0.74)[-0.741,0]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; NEURAL_HAM_LONG(-0.99)[-0.994,0] X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Feb 2020 12:35:54 -0000 On Fri, Feb 21, 2020 at 03:24:32AM -0600, Zhihao Yuan wrote: > On Thu, Feb 20, 2020 at 8:17 AM Konstantin Belousov 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.