Skip site navigation (1)Skip section navigation (2)
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>

index | next in thread | previous in thread | raw e-mail

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?  

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).  

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



help

Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75044DC7-D682-44A0-A384-E7B0C4D942DC>