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

[Markos Chandras <hwoarang@gentoo.org>]

On 12/28/2013 10:58 PM, Michał Górny wrote:
> Hello, folks.
> 
> I've noticed today that mips uses the same CHOST value for all three
> ABIs it supports:
> 
> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST}
> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST}
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}"
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}"
> 
> Long story short, this sucks and will cause trouble.
> 
> In the multilib stuff, we're using CHOST for two purposes:
> 
> 1. wrapped headers are put in /usr/include/$CHOST,
> 
> 2. multilib executables are prefixed with $CHOST-.
> 
> (1) here is not really a killer feature but I'd rather avoid changing
> this at this point. (2) is actually a killer feature, since the eclass
> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can
> find multilib *-config progs and stuff without any special hackery.
> 
> And those are just the examples I can think of. I suspect that more stuff
> may actually expect CHOST to uniquely identify build, especially some
> tricky hidden features in autotools :).
> 
> I'd suggest that you changed the CHOST values to uniquely identify ABI
> in use, at least in multilib profiles and preferably in all of them.
> 
(no particular answer at this point)

Just want to point out that debian uses these

mips64X-linux-gnuabin32, gnuabi64 etc.

I do see the benefits of having the default abi embedded into the CHOST
tuple but migrating to it may be quite painful.

-- 
Regards,
Markos Chandras