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 440CD138247 for ; Sun, 29 Dec 2013 21:48:33 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id C46E0E0B03; Sun, 29 Dec 2013 21:48:32 +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 4BF13E0B03 for ; Sun, 29 Dec 2013 21:48:32 +0000 (UTC) Received: from [192.168.1.2] (unknown [176.253.32.120]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: hwoarang) by smtp.gentoo.org (Postfix) with ESMTPSA id 3E8F533F711 for ; Sun, 29 Dec 2013 21:48:31 +0000 (UTC) Message-ID: <52C09892.2080607@gentoo.org> Date: Sun, 29 Dec 2013 21:48:02 +0000 From: Markos Chandras User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 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: gentoo-mips@lists.gentoo.org Subject: Re: [gentoo-mips] Re: On MIPS using the same CHOST for all multilib ABIs References: <20131228235839.5bb0305a@gentoo.org> <52C096B8.1020302@gentoo.org> In-Reply-To: <52C096B8.1020302@gentoo.org> X-Enigmail-Version: 1.6 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 16f7713a-953c-45d5-825f-da89d751563a X-Archives-Hash: 53be4cdd24e42c02178af9a2f9950b0f On 12/29/2013 09:40 PM, Joshua Kinard wrote: > On 12/28/2013 5:58 PM, Michał Górny wrote: >> Hello, folks. >> >> I've noticed today that mips uses the same CHOST value for all three >> ABIs it supports: >> >> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}" >> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST} >> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST} >> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}" >> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}" >> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}" >> >> Long story short, this sucks and will cause trouble. >> >> In the multilib stuff, we're using CHOST for two purposes: >> >> 1. wrapped headers are put in /usr/include/$CHOST, >> >> 2. multilib executables are prefixed with $CHOST-. >> >> (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. >> >> And those are just the examples I can think of. I suspect that more stuff >> may actually expect CHOST to uniquely identify build, especially some >> tricky hidden features in autotools :). >> >> 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 by > this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit > big/little endian CHOST, which means the o32 ABI. Why? mips64 can do o32 as well. > > According to this Debian wiki entry: > https://wiki.debian.org/Multiarch/Tuples Probably because they don't do mips64/o32. But we do, so we would also need *-linux-gnuabi32 -- Regards, Markos Chandras