Date: Thu, 13 Feb 2014 10:11:27 +0000 From: David Chisnall <theraven@FreeBSD.org> To: Alexander Kabaev <kabaev@gmail.com> 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: <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org> In-Reply-To: <20140212200413.71c6db5b@kan.dyndns.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>
next in thread | previous in thread | raw e-mail | index | archive | help
On 13 Feb 2014, at 01:04, Alexander Kabaev <kabaev@gmail.com> wrote: > 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. Perhaps you could share with the class. What is the correct way of = solving this problem? =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 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? David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75044DC7-D682-44A0-A384-E7B0C4D942DC>