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 BB5A5138247 for ; Sat, 28 Dec 2013 23:55:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7F75DE0A64; Sat, 28 Dec 2013 23:55:56 +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 0505FE0A64 for ; Sat, 28 Dec 2013 23:55:55 +0000 (UTC) Received: from [192.168.1.2] (unknown [2.126.0.130]) (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 7D21B33F5B5; Sat, 28 Dec 2013 23:55:54 +0000 (UTC) Message-ID: <52BF64EE.6010103@gentoo.org> Date: Sat, 28 Dec 2013 23:55:26 +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 CC: mips@gentoo.org, multilib@gentoo.org Subject: Re: [gentoo-mips] 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: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Archives-Salt: 808a9060-089b-42d6-a894-092a54074b44 X-Archives-Hash: 791ba622a6ec57314e60c7076144b2a7 On 12/28/2013 10: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. > (no particular answer at this point) Just want to point out that debian uses these mips64X-linux-gnuabin32, gnuabi64 etc. I do see the benefits of having the default abi embedded into the CHOST tuple but migrating to it may be quite painful. -- Regards, Markos Chandras