* Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs
@ 2014-01-22 21:07 99% ` Anthony G. Basile
0 siblings, 0 replies; 1+ results
From: Anthony G. Basile @ 2014-01-22 21:07 UTC (permalink / raw
To: gentoo-mips
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" <blueness@gentoo.org> 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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2013-12-28 22:58 [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs Michał Górny
2014-01-16 20:01 ` Michał Górny
2014-01-16 21:05 ` Anthony G. Basile
2014-01-16 21:24 ` Michał Górny
2014-01-16 22:29 ` Anthony G. Basile
2014-01-17 4:47 ` Michał Górny
2014-01-17 18:20 ` Markos Chandras
2014-01-17 18:51 ` Michał Górny
2014-01-17 19:44 ` Markos Chandras
2014-01-22 14:24 ` Anthony G. Basile
2014-01-22 14:38 ` Michał Górny
2014-01-22 20:39 ` Markos Chandras
2014-01-22 21:07 99% ` Anthony G. Basile
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox