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 40C32138247 for ; Wed, 22 Jan 2014 21:08:00 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id E3B1EE0B68; Wed, 22 Jan 2014 21:07:57 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 40750E0B67 for ; Wed, 22 Jan 2014 21:07:57 +0000 (UTC) Received: from [192.168.3.7] (cpe-74-77-145-97.buffalo.res.rr.com [74.77.145.97]) (using TLSv1 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: blueness) by smtp.gentoo.org (Postfix) with ESMTPSA id 4978633FB79 for ; Wed, 22 Jan 2014 21:07:56 +0000 (UTC) Message-ID: <52E0332F.3060003@gentoo.org> Date: Wed, 22 Jan 2014 16:07:59 -0500 From: "Anthony G. Basile" 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] On MIPS using the same CHOST for all multilib ABIs References: <20131228235839.5bb0305a@gentoo.org> <20140116210119.421c952c@pomiot.lan> <52D84994.3070306@opensource.dyc.edu> <20140116222418.6229a1b0@pomiot.lan> <52D85D57.9010500@gentoo.org> <20140117054718.5f948b88@pomiot.lan> <52D9746E.4020200@gentoo.org> <20140117195154.4b512793@pomiot.lan> <52D98807.2060201@gentoo.org> <52DFD4B7.8060306@gentoo.org> <20140122153822.278588a9@pomiot.lan> <52E02C65.1010102@gentoo.org> In-Reply-To: <52E02C65.1010102@gentoo.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Archives-Salt: 5154bf02-88f6-41e6-9248-767036e578f5 X-Archives-Hash: bf00a39fd859ecac69c1190c91f96688 On 01/22/2014 03:39 PM, Markos Chandras wrote: > On 01/22/2014 02:38 PM, Michał Górny wrote: >> Dnia 2014-01-22, o godz. 09:24:55 >> "Anthony G. Basile" napisał(a): >> >>> 4) The debian debate about departing from GNU tuples (aka triplets) is here: >>> >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664257 >>> https://wiki.debian.org/Multiarch/Tuples >>> https://wiki.debian.org/Multiarch/TuplesAbandoned >>> >>> Their reasons are different than ours. The concern was over >>> i386/486/585/686 inconsistencies and arm hard/soft float. Regarding the >>> later issue, gcc upstream suggested using the vendor field which is what >>> we do for hard/soft arm. >>> >>> 5) My recommendation is that the safest thing is to use the vendor field >>> since it is recognized as "arbitrary". [...] >> Well, considering that it will fix the underlying issue, you have my >> blessing :). If you are going to put 'gentoo' there somehow, even +2. >> > Do you mean change the CHOST for each ABI to contain the abi name in the > vendor field? That should work... > Yes. Something like armv7l-hardfloat-linux-gnueabi but for mips. eg for big endian mips I o32 uclibc we could have mips-o32-linux-uclibc. For little endian we'd have mipsel-o32-linux-uclibc. The only thing I'm not sure of is how to get higher isa in there. Maybe something like mips32r2-o32-linux-uclibc might work but I haven't looked at the gnu config stuff closely yet in this respect. And 64-bit little endian n32 glibc might be mips64el-n32-linux-gnu. Also, we need to be clear what we are talking about here. That stolen vendor field would just be the native abi because your compiler and binutils can be (for example) o32, but you can still build for n32 and n64 (provided your hardware can handle it). In fact on my lemote images (and probably all the multilib stages but I haven't looked), all my toolchain binaries are n32, except glibc which in /lib is o32, in /lib32 is n32and in /lib64 is n64 --- what abi your toolchain produces depends on what you pass to -mabi=. So I'm thinking the lemote tuple would look like mips64el-n32-linux-gnu but this doesn't mean the toolchain can only build for n32. I'm not sure if this solves mgorny's multilib issue or not. But something like mips64el-o32n32n64-linux-gnu is confusing and ugly. I'm going to miss the gentoo in there :( But, if we stick to *just* the vendor field, I should be able to change over my scripts easily and with one catalyst run have the new CHOST. Finally before we implement this, I'll draw up a chart. Let's discuss what we want first because one catalyst run on my old ubiquity boards is one week of time! I could cross compile much faster, but I like knowing that it works on native hardware. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : blueness@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA