From owner-svn-src-head@FreeBSD.ORG Thu Feb 13 10:11:37 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C33E010C; Thu, 13 Feb 2014 10:11:37 +0000 (UTC) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 8AC4D1214; Thu, 13 Feb 2014 10:11:37 +0000 (UTC) Received: from [192.168.0.7] (cpc28-cmbg15-2-0-cust64.5-4.cable.virginm.net [86.27.189.65]) (authenticated bits=0) by theravensnest.org (8.14.7/8.14.5) with ESMTP id s1DABVfm055515 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 13 Feb 2014 10:11:33 GMT (envelope-from theraven@FreeBSD.org) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Subject: Re: svn commit: r261801 - head/contrib/libc++/include From: David Chisnall In-Reply-To: <20140212200413.71c6db5b@kan.dyndns.org> Date: Thu, 13 Feb 2014 10:11:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <75044DC7-D682-44A0-A384-E7B0C4D942DC@FreeBSD.org> References: <201402121814.s1CIEo5A016765@svn.freebsd.org> <52FBC08C.30309@FreeBSD.org> <52FBC570.6080003@FreeBSD.org> <20140212200413.71c6db5b@kan.dyndns.org> To: Alexander Kabaev X-Mailer: Apple Mail (2.1827) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Dimitry Andric , Jung-uk Kim X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 10:11:37 -0000 On 13 Feb 2014, at 01:04, Alexander Kabaev 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