Re: [gentoo-mips] On MIPS using the same CHOST for all multilib ABIs

["Anthony G. Basile" <blueness@gentoo.org>]

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