1 |
Hello, folks. |
2 |
|
3 |
I've noticed today that mips uses the same CHOST value for all three |
4 |
ABIs it supports: |
5 |
|
6 |
arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}" |
7 |
arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST} |
8 |
arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST} |
9 |
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}" |
10 |
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}" |
11 |
arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}" |
12 |
|
13 |
Long story short, this sucks and will cause trouble. |
14 |
|
15 |
In the multilib stuff, we're using CHOST for two purposes: |
16 |
|
17 |
1. wrapped headers are put in /usr/include/$CHOST, |
18 |
|
19 |
2. multilib executables are prefixed with $CHOST-. |
20 |
|
21 |
(1) here is not really a killer feature but I'd rather avoid changing |
22 |
this at this point. (2) is actually a killer feature, since the eclass |
23 |
sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can |
24 |
find multilib *-config progs and stuff without any special hackery. |
25 |
|
26 |
And those are just the examples I can think of. I suspect that more stuff |
27 |
may actually expect CHOST to uniquely identify build, especially some |
28 |
tricky hidden features in autotools :). |
29 |
|
30 |
I'd suggest that you changed the CHOST values to uniquely identify ABI |
31 |
in use, at least in multilib profiles and preferably in all of them. |
32 |
|
33 |
-- |
34 |
Best regards, |
35 |
Michał Górny |