From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id B1E0C138247 for ; Sun, 29 Dec 2013 23:56:16 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 6FEE2E0B24; Sun, 29 Dec 2013 23:56:13 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id D627AE0B24 for ; Sun, 29 Dec 2013 23:56:12 +0000 (UTC) Received: from vapier.localnet (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 1C3DC33F622; Sun, 29 Dec 2013 23:56:12 +0000 (UTC) From: Mike Frysinger Organization: wh0rd.org To: gentoo-mips@lists.gentoo.org Subject: Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs Date: Sun, 29 Dec 2013 18:56:14 -0500 User-Agent: KMail/1.13.7 (Linux/3.12.1; KDE/4.6.5; x86_64; ; ) Cc: =?utf-8?q?Micha=C5=82_G=C3=B3rny?= , basile@opensource.dyc.edu References: <20131228235839.5bb0305a@gentoo.org> <52C09985.9000709@opensource.dyc.edu> <20131229230434.7c033ed0@gentoo.org> In-Reply-To: <20131229230434.7c033ed0@gentoo.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-mips@lists.gentoo.org Reply-to: gentoo-mips@lists.gentoo.org MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart4772296.KNSez1fIUk"; protocol="application/pgp-signature"; micalg=pgp-sha1 Content-Transfer-Encoding: 7bit Message-Id: <201312291856.15755.vapier@gentoo.org> X-Archives-Salt: 3da34ea8-efe7-4480-99c6-f99c5474d749 X-Archives-Hash: 96d559eb91f4e509a23dc7c24bf6cab7 --nextPart4772296.KNSez1fIUk Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable On Sunday 29 December 2013 17:04:34 Micha=C5=82 G=C3=B3rny wrote: > Dnia 2013-12-29, o godz. 16:52:05 "Anthony G. Basile" napisa=C5=82(a): > > On 12/29/2013 04:48 PM, Markos Chandras wrote: > > > Yes all 3 ABIs use the same tuple. > >=20 > > I think people are missing Mike's point from earlier, which is that > > tuples label toolchains and a toolchain can support multiple abis. So > > for example, what would one do on a system which simultaneously has o32, > > n32 and n64? -gnuabi32n32n64 looks pretty crazy. >=20 > I'd say that we shouldn't limit the concept of 'toolchain' to > specifically GNU binutils + GNU gcc. Configure scripts can require much > more tools (like assemblers, *-config tools including pkg-config) > and I doubt we should really assume they all have some magic support > for ABI switching we had taken care of. the problem you pointed out is a limitation in our code: we cannot assume=20 CHOST is unique for an ABI, thus using that as a unique path in generating = ABI=20 headers is wrong. conflating that bug in our code with any other issue is= =20 wrong. you can easily use ${CHOST}/${ABI} or ${CHOST}-${ABI} or just ${ABI= }=20 (since /usr/include is already associated with ${CHOST}). when it comes to *-config tools, those are known to be old and crap (for ma= ny=20 more reasons than just multilib/cross-compiling). convert to .pc files and= use=20 pkg-config instead. > That said, it would be actually more reasonable to have three separate > triples for those ABIs, and link them to the same application if it > supports all three ABIs. Of course, we would need to ensure that > the application actually respects the triple via which it was called. creating a unique tuple is feasible via the vendor field as a last resort. = =20 however, unless you have a compelling reason to do so, i don't think it mak= es=20 sense to pursue it. other than the vendor field, we are limited by what=20 upstream GNU does and in that regard, they haven't always used unique tuple= s=20 for ABI selection (this isn't limited to MIPS either). so to turn your base argument around, we shouldn't be limiting Gentoo to on= ly=20 support CHOSTs that also select ABIs uniquely. =2Dmike --nextPart4772296.KNSez1fIUk Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.17 (GNU/Linux) iQIcBAABAgAGBQJSwLafAAoJEEFjO5/oN/WB0tsP/R/6xca6kYwdWTj2ziS5Xe5r xlk+6f+kkLGKjx4PDQe3pu5M+zgGSkbhzzJCydtmT7aS9NnC8oRTZfb774GBriSN RD4CmjaQOMEaraCXKZ/TFQQRvpIThevH9hjiskj1bhmHpG/7yI2SpjNzdP7I/3E1 HbZ/8OsDXn4opfNcVB3DZvyf1ovbHzXfJe1LIbQLzmbCa8+RoRLgtN4VzNodPR5B EzP5ARyBQRtGNqNZF6FkTPOQ2xGpBlPX3lB9qf/fVrvRE5ODV+K4EYlgDuvXdX1c Et7l8P1sI+JUfBO24R2StJl69QBwXikDyeLfOttUJaghZtaP03jxoNHIwfY32Hjk kTl4Iuna37Ti3o3F8XmAOg+kf0yqdcnmD/eJaeR6rrTYwkT+JbbfWQwNf/esaiF3 tUtDZg+ZQIYFRD5P65TW/jHzJsNaFKVy7ExsfUF/Bfwzg+H7FaxOL11pHvLdcxXT vASjoAyjpNfljsBx6hzg7c52Q0dTdSKnqkfVPYvURFlMpZE3UzEt2H0K3dxxiXzv Tt/h2lKXHG51xL3NhVki/pvsIUjzV2kRXyPRz4i4XzXo06XijZ0ITb8mZkObB8Y5 qBuk9JI+ZijHcWQCkj/+BaOTjRRZM1XUk1pC07pbMNTVddu5Ags2fOhcLWxCbfBG fe/zgfyu6imYWtt0TdM/ =bjZs -----END PGP SIGNATURE----- --nextPart4772296.KNSez1fIUk--