From owner-svn-src-all@FreeBSD.ORG Sat Mar 24 18:46:17 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 528E1106564A; Sat, 24 Mar 2012 18:46:17 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from mail.zoral.com.ua (mx0.zoral.com.ua [91.193.166.200]) by mx1.freebsd.org (Postfix) with ESMTP id B8D868FC15; Sat, 24 Mar 2012 18:46:16 +0000 (UTC) Received: from skuns.kiev.zoral.com.ua (localhost [127.0.0.1]) by mail.zoral.com.ua (8.14.2/8.14.2) with ESMTP id q2OIk6UN069558; Sat, 24 Mar 2012 20:46:06 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5) with ESMTP id q2OIk5DN025467; Sat, 24 Mar 2012 20:46:05 +0200 (EET) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.5/8.14.5/Submit) id q2OIk5gW025466; Sat, 24 Mar 2012 20:46:05 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Sat, 24 Mar 2012 20:46:05 +0200 From: Konstantin Belousov To: Alexander Kabaev Message-ID: <20120324184605.GW2358@deviant.kiev.zoral.com.ua> References: <201203232010.q2NKAuIE092217@svn.freebsd.org> <20120323202335.GM2358@deviant.kiev.zoral.com.ua> <20120323164922.0bac354e@kan.dyndns.org> <20120323211038.GR2358@deviant.kiev.zoral.com.ua> <9FDB5808-2EE9-4F38-86E6-D0C115E7677C@FreeBSD.org> <20120324115421.28471627@kan.dyndns.org> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="vOCZ4jhp7iwOpVgV" Content-Disposition: inline In-Reply-To: <20120324115421.28471627@kan.dyndns.org> User-Agent: Mutt/1.4.2.3i X-Virus-Scanned: clamav-milter 0.95.2 at skuns.kiev.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-4.0 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on skuns.kiev.zoral.com.ua Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Chisnall Subject: Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++ X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Mar 2012 18:46:17 -0000 --vOCZ4jhp7iwOpVgV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 24, 2012 at 11:54:21AM -0400, Alexander Kabaev wrote: > On Fri, 23 Mar 2012 23:39:44 +0000 > David Chisnall wrote: >=20 > > On 23 Mar 2012, at 21:10, Konstantin Belousov wrote: > >=20 > > > The patch just committed made the base-shipped library incompatible > > > with the ports and manual libstdc++ builds. > >=20 > > To clarify - the one shipped in the base system has been incompatible > > with the one in ports since late 2007... > > > That says something about the extend of the breakage, does it not? > =20 > > In future, however, we will want libstdc++ in ports to be using the > > system ABI library (e.g. libcxxrt) so that it can be linked with > > libraries using the system C++ stack, so the layout of std::type_info > > in its headers doesn't matter too much because it won't be used. > >=20 > > > I think it is wiser to > > > not 'undo the undo', and instead start living with the > > > upstream-approved ABI. For symvered library, it does not make any > > > difference if you break it in 10.0 or 9.1. > >=20 > > Not true. The vtable layout can not be symbol versioned > > effectively. The std::type_info class is required by the ABI to > > exist (and is in libsupc++ / libcxxrt, so is independent of our STL > > implementation, either libstdc++ or libc++). Users expect to be able > > to cast=20 > >=20 > > > Also, I think that consumers that depend of the ABI of > > > std::typeinfo can be hacked to understand the layout of vtable. > >=20 > > Supporting both layouts is not really tenable. We need to do one of > > the following: > >=20 > > - Say 'we are going to break this now!' and force people to recompile > > libsupc++, libcxxrt, and libobjc2. > > - Keep the layout that we currently ship and patch in > > ports. > >=20 > > I don't mind which of these we do since I'm not the one that has to > > do the work in ensuring compatibility with ports but it will need to > > pick one and then stick to it... > >=20 > > > I doubt that there are > > > many users that utilize typeinfo. > >=20 > > Yes, to my knowledge there are three, and two of them are me :-( > >=20 >=20 > I will support the switch to 'default' ABI used upstream, provided > David is onboard. The breakage is very limited at the moment and > can only grow over time, so will grow the pain, while we insist on being > diverged from GCC. We might as well bite the bullet and live through > this at the cost of 9.1 release errata that only affects libobjc2. Right, this was my point, and you seems to agree with me: better to make a switch back to the upstream ABI sooner (9.1) rather then later (10.0). --vOCZ4jhp7iwOpVgV Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (FreeBSD) iEYEARECAAYFAk9uFm0ACgkQC3+MBN1Mb4glOQCgxbJGYl+4OcyaETdEnknM6tGH XKsAoKvvlTItoPErlV3lxfif9D/nXCUe =NmuK -----END PGP SIGNATURE----- --vOCZ4jhp7iwOpVgV--