Gentoo Archives: gentoo-mips

From: "Anthony G. Basile" <blueness@g.o>
To: gentoo-mips@l.g.o
Subject: Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs
Date: Wed, 22 Jan 2014 21:08:00
Message-Id: 52E0332F.3060003@gentoo.org
In Reply to: Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs by Markos Chandras
1 On 01/22/2014 03:39 PM, Markos Chandras wrote:
2 > On 01/22/2014 02:38 PM, Michał Górny wrote:
3 >> Dnia 2014-01-22, o godz. 09:24:55
4 >> "Anthony G. Basile" <blueness@g.o> napisał(a):
5 >>
6 >>> 4) The debian debate about departing from GNU tuples (aka triplets) is here:
7 >>>
8 >>> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664257
9 >>> https://wiki.debian.org/Multiarch/Tuples
10 >>> https://wiki.debian.org/Multiarch/TuplesAbandoned
11 >>>
12 >>> Their reasons are different than ours. The concern was over
13 >>> i386/486/585/686 inconsistencies and arm hard/soft float. Regarding the
14 >>> later issue, gcc upstream suggested using the vendor field which is what
15 >>> we do for hard/soft arm.
16 >>>
17 >>> 5) My recommendation is that the safest thing is to use the vendor field
18 >>> since it is recognized as "arbitrary". [...]
19 >> Well, considering that it will fix the underlying issue, you have my
20 >> blessing :). If you are going to put 'gentoo' there somehow, even +2.
21 >>
22 > Do you mean change the CHOST for each ABI to contain the abi name in the
23 > vendor field? That should work...
24 >
25 Yes. Something like armv7l-hardfloat-linux-gnueabi but for mips. eg for
26 big endian mips I o32 uclibc we could have mips-o32-linux-uclibc. For
27 little endian we'd have mipsel-o32-linux-uclibc. The only thing I'm not
28 sure of is how to get higher isa in there. Maybe something like
29 mips32r2-o32-linux-uclibc might work but I haven't looked at the gnu
30 config stuff closely yet in this respect. And 64-bit little endian n32
31 glibc might be mips64el-n32-linux-gnu.
32
33 Also, we need to be clear what we are talking about here. That stolen
34 vendor field would just be the native abi because your compiler and
35 binutils can be (for example) o32, but you can still build for n32 and
36 n64 (provided your hardware can handle it). In fact on my lemote images
37 (and probably all the multilib stages but I haven't looked), all my
38 toolchain binaries are n32, except glibc which in /lib is o32, in /lib32
39 is n32and in /lib64 is n64 --- what abi your toolchain produces depends
40 on what you pass to -mabi=. So I'm thinking the lemote tuple would look
41 like mips64el-n32-linux-gnu but this doesn't mean the toolchain can only
42 build for n32. I'm not sure if this solves mgorny's multilib issue or
43 not. But something like mips64el-o32n32n64-linux-gnu is confusing and ugly.
44
45 I'm going to miss the gentoo in there :( But, if we stick to *just* the
46 vendor field, I should be able to change over my scripts easily and with
47 one catalyst run have the new CHOST.
48
49 Finally before we implement this, I'll draw up a chart. Let's discuss
50 what we want first because one catalyst run on my old ubiquity boards is
51 one week of time! I could cross compile much faster, but I like knowing
52 that it works on native hardware.
53
54 --
55 Anthony G. Basile, Ph.D.
56 Gentoo Linux Developer [Hardened]
57 E-Mail : blueness@g.o
58 GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
59 GnuPG ID : F52D4BBA