From owner-svn-src-head@FreeBSD.ORG Fri Mar 23 23:40:00 2012 Return-Path: Delivered-To: svn-src-head@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id CE447106564A; Fri, 23 Mar 2012 23:40:00 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theravensnest.org [109.169.23.128]) by mx1.freebsd.org (Postfix) with ESMTP id 467C28FC18; Fri, 23 Mar 2012 23:39:59 +0000 (UTC) Received: from [192.168.0.2] (cpc1-cwma8-2-0-cust257.7-3.cable.virginmedia.com [82.20.153.2]) (authenticated bits=0) by theravensnest.org (8.14.4/8.14.4) with ESMTP id q2NNdofK038880 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Fri, 23 Mar 2012 23:39:53 GMT (envelope-from theraven@FreeBSD.org) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: David Chisnall In-Reply-To: <20120323211038.GR2358@deviant.kiev.zoral.com.ua> Date: Fri, 23 Mar 2012 23:39:44 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: <9FDB5808-2EE9-4F38-86E6-D0C115E7677C@FreeBSD.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> To: Konstantin Belousov X-Mailer: Apple Mail (2.1257) Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, src-committers@FreeBSD.org, Alexander Kabaev Subject: Re: svn commit: r233391 - head/contrib/libstdc++/libsupc++ X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.5 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: Fri, 23 Mar 2012 23:40:00 -0000 On 23 Mar 2012, at 21:10, Konstantin Belousov wrote: > The patch just committed made the base-shipped library incompatible > with the ports and manual libstdc++ builds. To clarify - the one shipped in the base system has been incompatible = with the one in ports since late 2007... 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. > 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. 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 > Also, I think that consumers that depend of the ABI of std::typeinfo = can > be hacked to understand the layout of vtable. Supporting both layouts is not really tenable. We need to do one of the = following: - 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 in ports. 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... > I doubt that there are > many users that utilize typeinfo. Yes, to my knowledge there are three, and two of them are me :-( David=