Date: Sat, 24 Mar 2012 20:46:05 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alexander Kabaev <kabaev@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, David Chisnall <theraven@freebsd.org> Subject: Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++ Message-ID: <20120324184605.GW2358@deviant.kiev.zoral.com.ua> In-Reply-To: <20120324115421.28471627@kan.dyndns.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
--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 <theraven@FreeBSD.org> 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 <typeinfo> 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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120324184605.GW2358>