From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 26 16:50:10 2013 Return-Path: Delivered-To: toolchain@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id CA2EEAC5 for ; Sat, 26 Jan 2013 16:50:10 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from theravensnest.org (theraven.freebsd.your.org [216.14.102.27]) by mx1.freebsd.org (Postfix) with ESMTP id 8B830777 for ; Sat, 26 Jan 2013 16:50:09 +0000 (UTC) Received: from [192.168.0.2] (cpc10-cmbg15-2-0-cust123.5-4.cable.virginmedia.com [86.30.246.124]) (authenticated bits=0) by theravensnest.org (8.14.5/8.14.5) with ESMTP id r0QGZbIJ085065 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES128-SHA bits=128 verify=NO); Sat, 26 Jan 2013 16:35:38 GMT (envelope-from theraven@FreeBSD.org) Subject: Re: Removing default build of gcc Mime-Version: 1.0 (Apple Message framework v1278) Content-Type: multipart/signed; boundary="Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9"; protocol="application/pgp-signature"; micalg=pgp-sha1 From: David Chisnall In-Reply-To: <20130126152225.GC2522@kib.kiev.ua> Date: Sat, 26 Jan 2013 16:35:31 +0000 Message-Id: <8A0C6AD5-F247-4488-B44A-85AC2D539D4D@FreeBSD.org> References: <74D8E686-3679-46F2-8A08-4CF5DFC020CA@FreeBSD.org> <20130125113122.GN2522@kib.kiev.ua> <20130125195941.GW2522@kib.kiev.ua> <20130126152225.GC2522@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1278) Cc: toolchain@FreeBSD.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Jan 2013 16:50:10 -0000 --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On 26 Jan 2013, at 15:22, Konstantin Belousov wrote: > Your initial assesment of the problem as a misbehaviour of the = combination > of filtering and versioning made no sense to me, I asked you to = provide > the isolated test case, which you did not. The test case in the PR was such a test case. libstdc++ and libsupc++ = export a few symbols (including the ones that I mentioned in the email = that you are replying to) with different versions. The end result is = that you get some cases where some code (typically in libsupc++)=20 I am not claiming that this is an rtld bug, so I don't know why you keep = going on about it as if I am. I do not know why you want me to provide = you with an isolated test case for a bug that is assigned to me and that = I am in the process of fixing. > Our implementation of filters indeed only allows for the filtered > symbol to have the same version as the filtee symbol. I re-read the > SUN documentation about filters (who had designed them), and looked at > what Linux does there. It seems to me that Sun document spirit forces > us to behave in a way which our rtld currently does. Linux behaviour = is > useless there, IMHO, since their rtld just inserts filtee before = filter > in the global lookup order (I may be wrong there). This is COMPLETELY IRRELEVANT to the bug in question, which is that our = libcxxrt and libsupc++ version scripts have some incorrect symbol = versions. > I do suggest (again) that the way to fix the issue is to provide the > isolated test-case and decide if the behaviour of rtld is right. It is correct. I am not claiming it is incorrect. I don't know why you = keep repeating that I am. =20 > If we > conclude that the problem is not in rtld but in the versioning = mismatch > between libraries (libstdc++ and libsupc++), I again suggest to = provide > the patch for review first. The ABI seems to become too unwieldly, and > making ad-hoc changes there could paint us into the corner. I have a patch, which fixes it in some cases and has been tested, but = misses some others. I am preparing a patch that fixes the versioning = consistently across libsupc++ and libcxxrt to match libstdc++. I want = to do this as a single patch, rather than an ad hoc series of changes. = My aim is, as it has always been, to preserve the existing ABI.=20 David= --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.18 (Darwin) iQIcBAEBAgAGBQJRBAXTAAoJEKx65DEEsqIdbcsQALSJ8dbfVWKtXszQc+p6wJG2 cA4mHmRaeDUBcJ0iCwIQQhtwysmYLZ3varoPoOs/2GDZI1LXxXlmThbjOyn57K3x 2GtKju7UaZFxxcWBfEvv5Je4gUXpXDUxuqtzbalMKjHFrrkFRvDLv2z1P57md5Aa 3BxMmg3cnq41qcHdq2Uepq+Vg87UCo76MHGgs9JR5CWSVDqG9FYEu+rZG7Pcr/jd cYRoX/GuG+GCvzJnEc7i/eSPmJD1YhMG6qHPw9lXlewo0nehg0HBENgfhFr5AHo9 /02mD5XzoI3BI8RfeeUKNDkhrPdeqEXR8K5eDvzjf73eCke5kQ1jQio6zhx/O/2Q FHpQ5MXfOeRGsXdjeshktUSgJFH6N5ToepO2EcJ8E4x7y+I82E5ylU2b1OCJ/DGZ H/4zIXw852oXF8Fua4qeIIGOufQirBAY5xY2Bm4Bd/QN6k89NKb7e7e2MP6CSumz Q6GM4TPDI+Ixvvmi5tF7lPyrYaLDDCChWBZK5oAeifLh7yAV6u49T4ykQ81QjTtj 4LiyvRxf03u1yeioX8MKwzJ3ITrcamRlQCcJzrDLThGS9uBNWRefYf32yq3tAeZt wtE/WdDngiivL0OS9a0cGn8FB7tVcRiyv+NxPChj6v2tPQK2uZN1x+ZZmrB+rtt6 UNSN371KvxhVl3jL9mGq =HW4T -----END PGP SIGNATURE----- --Apple-Mail=_C354B446-9C6A-4FEB-A92E-AAE327FE74D9--