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

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

On 01/17/2014 02:44 PM, Markos Chandras wrote:
> On 01/17/2014 06:51 PM, Michał Górny wrote:
>> Dnia 2014-01-17, o godz. 18:20:30
>> Markos Chandras <hwoarang@gentoo.org> napisał(a):
>>
>>> On 01/17/2014 04:47 AM, Michał Górny wrote:
>>>> Dnia 2014-01-16, o godz. 17:29:43 "Anthony G. Basile"
>>>> <blueness@gentoo.org> napisał(a):
>>>>
>>>>> On 01/16/2014 04:24 PM, Michał Górny wrote:
>>>>>> Because AC_PATH_TOOL uses CHOST and some random Gentoo
>>>>>> invention.
>>>>> I got that AC_PATH_TOOL and AC_CHECK_TOOL prefix whatever utility
>>>>> they search for with the canonicalized chost (usually from
>>>>> config.guess), but I still don't see why we need this to avoid
>>>>> hackery?  Can you give me a practial example because right now I
>>>>> just don't see a serious problem.
>>>> libgpg-error installs ${CHOST}-gpg-error-config.
>>>>
>>>> Now libgcrypt (and possibly other tools) are using AC_PATH_TOOL to
>>>> find it. If we have proper CHOSTs, they find the right
>>>> gpg-error-config and we don't have to put any more effort into
>>>> that. Then libgcrypt installs ${CHOST}-libgcrypt-config.
>>>>
>>>> Now other tools are using AC_PATH_TOOL to find proper
>>>> libgcrypt-config. If we have proper CHOSTs, it just works and we
>>>> don't have to put any more effort into that.
>>>>
>>>> Same goes for LLVM & Mesa.
>>>>
>>>> If we play by the rules nicely, all pieces fit together nicely and
>>>> we don't have to worry. If we don't, we ask the developers to spit
>>>> Gentoo- specific hackery all over the place.
>>>>
>>> You need to consider that besides changing CHOST to new stages (which
>>> is a lengthy and tiring process), you somehow need to migrate existing
>>> users to the new CHOST (no?) otherwise the multilib eclass (or any
>>> other eclass/package) that depends on CHOST will be broken as soon as
>>> they update their tree and try to install package updates.
>>> This is definitely not a pleasant user experience.
>> Well, I'd like someone who knows better than I do to explain how much
>> does changing non-native CHOST affect. I will try to test it a bit by
>> changing CHOST_x86=i686-pc-linux-gnu to i386-* locally but an expert
>> opinion would be preferred.
>>
> My comment was not on what side-effects changing the CHOST may have, but
> it requires time and effort for every MIPS user out there. You also need
> to consider that many people have relatively slow MIPS hardware (routers
> and stuff) that will take a good couple of days (if not more) to switch
> to a new CHOST. But still, not everyone is going to do it and forcing
> them is definitely unpleasant.
>
My concern has been departing from GNU tuple standard which makes only 
restricted assumptions (see below) about abi.  For this, I've always 
referred to the GNU config project which is supposed to guess the tuple 
for any system you're on.  So, try this ...

1) git clone git://git.sv.gnu.org/config.git

2) cd config

3) ./config.guess

Here are my results (I hope this table survives email munging!)



On my multilib amd64 box I get:
config.guess:   x86_64-unknown-linux-gnu
I use:               x86_64-pc-linux-gnu

On my multilib o32/n32/n64 lemote yeeloong:
config.guess:       mips64el-unknown-linux-gnu
I use:                   mips64el-unknown-linux-gnu

On my unilib amd64 uclibc I get:
config.guess:      x86_64-unknown-linux-uclibc
I use:                  x86_64-gentoo-linux-uclibc

On my unilib o32 mips32r2 I get:
  config.guess:     mips-unknown-linux-uclibc
  I use:                 mips-gentoo-linux-uclibc

On my chromebook glibc/eabi/hf:
config.guess:   armv7l-unknown-linux-gnueabihf
I use:               armv7a-hardfloat-linux-gnueabi

On my chromebook uclibc/eabi/hf
config.guess:   armv7l-unknown-linux-uclibceabihf
I use:               armv7a-hardfloat-linux-uclibceabi


Note: 1) the second field, the so-called vendor field, is arbitrary.  I 
like putting -gentoo- in there.  2) Only arm mixes in abi and 
hard/softfloat stuff.

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".  I've been through abusing fields 
before, albeit in a different situation: with glibc and elf headers when 
we did pax marking in the elf header's e_ident[] field, bytes 14 and 
15.  Upstream grsec/pax developers originally used that for pax marking 
until Drepper decide to use those bytes for something else.  On 
upgrading glibc, using chpax to do EI_PAX marking broke whatever it touched.

-- 
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