Date: Thu, 13 Feb 2014 10:29:22 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: David Chisnall <theraven@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric <dim@FreeBSD.org>, Jung-uk Kim <jkim@FreeBSD.org> Subject: Re: svn commit: r261801 - head/contrib/libc++/include Message-ID: <20140213102922.240cbcb0@kan.dyndns.org> In-Reply-To: <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org> References: <201402121814.s1CIEo5A016765@svn.freebsd.org> <52FBC08C.30309@FreeBSD.org> <DC94BE69-D2BD-4BFB-B4D2-080CC22E01CA@FreeBSD.org> <52FBC570.6080003@FreeBSD.org> <20140212200413.71c6db5b@kan.dyndns.org> <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/kYQpGtjrlkV5=ty9S6UDFvW Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Thu, 13 Feb 2014 10:11:27 +0000 David Chisnall <theraven@FreeBSD.org> wrote: > On 13 Feb 2014, at 01:04, Alexander Kabaev <kabaev@gmail.com> wrote: >=20 > > The refusal to use tools that are there precisely to help to help > > with the binary compatibility in favor of mindless library bumps is > > just sad. >=20 > Perhaps you could share with the class. What is the correct way of > solving this problem? =20 >=20 > For those just joining the discussion, the issue is that std::pair > was originally declared with an explicit constructor and should have > an implicit constructor, which has a different calling convention. > This means that we can't share the two std::pair implementations > across libraries, because they will try to call the constructor with > the wrong arguments. Because of templates and C++ name mangling, > this ends up being propagated into most libraries that link against > libc++, and calling from one with the old definition to one with the > new definition end up causing segfaults (if we're lucky - I think the > symptom that we're seeing is actually dereferencing a junk value in a > register, so it may cause random memory writes, but I'd have to check > the ABI). =20 >=20 > Given that neither redeclaring the new std::pair in a new namespace, > nor exporting both constructor symbols using symbol versioning (the > two approaches that we've already discussed) will work, what are the > tools that apparently we're refusing to use that will work? >=20 > David OK, I think the confusion has started because reported to this as an ABI incompatibility within libc++ itself, which is not the case here. When calling convention of a public symbol changes, one can put the old definition under the compatibility version that is only available for runtime binding, this allowing old binaries to work and that is what I was referring to. Unfortunately, that won't work in this case because libc++ proper does NOT export any symbols with 'pair' in them, so it is not affected by the ABI breakage itself. What libc++ developers did is they exported ABI breakage into every binary that was compiled with different revisions on libc++ _header_ files, not linked with the library proper. Using the library major version as a circumstantial evidence indicating header versions binary was compiled with might work then, though is not 100% reliable. Theoretically one can compile the binary that uses std::pair template but does not record libc++ as the runtime dependency. Still, that is better than nothing. ABI stability and C++ apparently should be mentioned in the same sentence, unless there's also a 'pipe dream' in it. And you do deserve an apology for my remark.=20 --=20 Alexander Kabaev --Sig_/kYQpGtjrlkV5=ty9S6UDFvW Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iD8DBQFS/OTXQ6z1jMm+XZYRAoW2AKDc/lS0wcFkKHoW3MP3KSX+0u0EUQCglpN9 t8+VXjZKKlsirllH/I24JkY= =T+Om -----END PGP SIGNATURE----- --Sig_/kYQpGtjrlkV5=ty9S6UDFvW--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20140213102922.240cbcb0>