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 DB4D7138247 for ; Sun, 29 Dec 2013 21:40:19 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 69D54E0AB5; Sun, 29 Dec 2013 21:40:19 +0000 (UTC) Received: from qmta06.westchester.pa.mail.comcast.net (qmta06.westchester.pa.mail.comcast.net [76.96.62.56]) by pigeon.gentoo.org (Postfix) with ESMTP id E13A0E0AB5 for ; Sun, 29 Dec 2013 21:40:18 +0000 (UTC) Received: from omta20.westchester.pa.mail.comcast.net ([76.96.62.71]) by qmta06.westchester.pa.mail.comcast.net with comcast id 7ZHZ1n0031YDfWL56ZgJ8a; Sun, 29 Dec 2013 21:40:18 +0000 Received: from [192.168.1.13] ([69.251.154.25]) by omta20.westchester.pa.mail.comcast.net with comcast id 7ZgH1n00Z0Z8pnp3gZgJgV; Sun, 29 Dec 2013 21:40:18 +0000 Message-ID: <52C096B8.1020302@gentoo.org> Date: Sun, 29 Dec 2013 16:40:08 -0500 From: Joshua Kinard User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 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 To: =?UTF-8?B?TWljaGHFgiBHw7Nybnk=?= , gentoo-mips@lists.gentoo.org CC: mips@gentoo.org, multilib@gentoo.org Subject: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs References: <20131228235839.5bb0305a@gentoo.org> In-Reply-To: <20131228235839.5bb0305a@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aOFxeqUNnEHKefAALsLoPTQv4Isv3NotG" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1388353218; bh=aAI/07YhH7PFagghAO889H6WY4+3WEFJqm8NJ35BgQ4=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=OxCWkzK/YwOzsjf9P+AyH0EE2RQ6eRYHoeAHpu+o1KAMqU9t7/hnVmzy5SVi5vizv wKMpazKkN4oaV/S3bq5C/Ud5SRygIWlpeunz4XaOa/jF6bKnZM66vgGdiFdNGctMCH /+VyAimJzNISXrz3+zQH4l9NqIdoH2MdJWimikmcfbDEpKp4kk+uP6D7sDZssAfVo5 9Uq/l045/WxFD1vuPjyi7W0legFtH8OuYb8dMsM+/YQS1DiOeGny3aUtlFhsK/HkJD SiD1aVsnINHYfI0gv95Mcr4tMh1xY4xrINZGwggBKy3N3gVw0ate2nno84ap4TtpyG 7kdjVhzaAfEew== X-Archives-Salt: 6a346dbd-54e2-4697-8bf6-ffde7e4ff305 X-Archives-Hash: 72846c3018a2cd84638f882135861b89 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --aOFxeqUNnEHKefAALsLoPTQv4Isv3NotG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 12/28/2013 5:58 PM, Micha=C5=82 G=C3=B3rny wrote: > Hello, folks. >=20 > I've noticed today that mips uses the same CHOST value for all three > ABIs it supports: >=20 > arch/mips/mips64/multilib/make.defaults:CHOST_o32=3D"${CHOST}" > arch/mips/mips64/multilib/make.defaults:CHOST_n32=3D${CHOST} > arch/mips/mips64/multilib/make.defaults:CHOST_n64=3D${CHOST} > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32=3D"${CHOST}"= > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32=3D"${CHOST}"= > arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64=3D"${CHOST}"= >=20 > Long story short, this sucks and will cause trouble. >=20 > In the multilib stuff, we're using CHOST for two purposes: >=20 > 1. wrapped headers are put in /usr/include/$CHOST, >=20 > 2. multilib executables are prefixed with $CHOST-. >=20 > (1) here is not really a killer feature but I'd rather avoid changing > this at this point. (2) is actually a killer feature, since the eclass > sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can > find multilib *-config progs and stuff without any special hackery. >=20 > And those are just the examples I can think of. I suspect that more stu= ff > may actually expect CHOST to uniquely identify build, especially some > tricky hidden features in autotools :). >=20 > I'd suggest that you changed the CHOST values to uniquely identify ABI > in use, at least in multilib profiles and preferably in all of them. Matt can probably vouch for this better, but the only two ABIs affected b= y this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit big/little endian CHOST, which means the o32 ABI. mips64[el]-unknown-linux-gnu means either n32 or n64. So no change shoul= d be needed for o32-based installs. According to this Debian wiki entry: https://wiki.debian.org/Multiarch/Tuples We would have to adopt mips64[el]-unknown-linux-gnuabin32 for n32 and -gnuabin64 for n64. Testing would be needed to watch for packages that don't have updated config.sub/config.guess files and fail to recognize th= is particular CHOST. --=20 Joshua Kinard Gentoo/MIPS kumba@gentoo.org 4096R/D25D95E3 2011-03-28 "The past tempts us, the present confuses us, the future frightens us. A= nd our lives slip away, moment by moment, lost in that vast, terrible in-bet= ween." --Emperor Turhan, Centauri Republic --aOFxeqUNnEHKefAALsLoPTQv4Isv3NotG Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQIcBAEBAgAGBQJSwJbAAAoJENsjoH7SXZXjkXIP/R5g5ES5U8YJ5bP6v44u1LIz bH54FbOwKqXEO3cughm6LjSV2udBz9fcb/SbO6Vi5QrhPy8hzDvHfjdtw9Bxy4gB gfln4QCD1fhjcFCFZQmzKlizcEaD7zXRBWxxJzcigyTMrP1VpqZfZvtqBU0SNba2 WtjSkRq3XUhxAGbWws5l3dyR6iwONVILY8hoANWgdAXv3Q4pnmyETYiV+8Yz0bdq wpSi4glcP9vO0WaVo2GIL7Dd3i03jT1mf6t4XXOdW2m7W/Qo0/Ar4nd2Fitz+4f7 2w/rFGTWOO38NTVoszCwWfdVvpltUg1cEFHTyYfefxzxHdPBi0X7guDG//i5g0jm xbskWyGhND3b8b4XW1KJ12zMQmibro1Qi4l5YDBxLlpI2n+B+hV7w0k/D7lo1q0B VTSYTT7rCUpqJscH+mSZyy41lZDXWAzNRmg+obZ+UQ2LEIolYth096uIlKmF5Xg2 yd19wIFRtFw48CqCCfHz7aDGAWqiqcfC2uPBXxp9ycBqw4d+LKGXh/FjbNDr1kFN zXHT5fYz08Ynck2Lhr/s+QMNcUGClLI1R4Pz1yPO3hyZ3qCpPijnsGIpb4fsyEFL VlUeylt72sByL3k3r8nboWgOWWqdjzwhSJH5vL7AK9hgWxVNIiqhAh/EAZDh4gn1 kFSs5Y4TJ0Qv4qiUsoRw =g/OI -----END PGP SIGNATURE----- --aOFxeqUNnEHKefAALsLoPTQv4Isv3NotG--