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.

-- 
Best regards,
Michał Górny