1 |
On 12/28/2013 10:58 PM, Michał Górny wrote: |
2 |
> Hello, folks. |
3 |
> |
4 |
> I've noticed today that mips uses the same CHOST value for all three |
5 |
> ABIs it supports: |
6 |
> |
7 |
> arch/mips/mips64/multilib/make.defaults:CHOST_o32="${CHOST}" |
8 |
> arch/mips/mips64/multilib/make.defaults:CHOST_n32=${CHOST} |
9 |
> arch/mips/mips64/multilib/make.defaults:CHOST_n64=${CHOST} |
10 |
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_o32="${CHOST}" |
11 |
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n32="${CHOST}" |
12 |
> arch/mips/mipsel/mips64el/multilib/make.defaults:CHOST_n64="${CHOST}" |
13 |
> |
14 |
> Long story short, this sucks and will cause trouble. |
15 |
> |
16 |
> In the multilib stuff, we're using CHOST for two purposes: |
17 |
> |
18 |
> 1. wrapped headers are put in /usr/include/$CHOST, |
19 |
> |
20 |
> 2. multilib executables are prefixed with $CHOST-. |
21 |
> |
22 |
> (1) here is not really a killer feature but I'd rather avoid changing |
23 |
> this at this point. (2) is actually a killer feature, since the eclass |
24 |
> sets CHOST properly and thanks to that AC_CHECK_TOOL and friends can |
25 |
> find multilib *-config progs and stuff without any special hackery. |
26 |
> |
27 |
> And those are just the examples I can think of. I suspect that more stuff |
28 |
> may actually expect CHOST to uniquely identify build, especially some |
29 |
> tricky hidden features in autotools :). |
30 |
> |
31 |
> I'd suggest that you changed the CHOST values to uniquely identify ABI |
32 |
> in use, at least in multilib profiles and preferably in all of them. |
33 |
> |
34 |
(no particular answer at this point) |
35 |
|
36 |
Just want to point out that debian uses these |
37 |
|
38 |
mips64X-linux-gnuabin32, gnuabi64 etc. |
39 |
|
40 |
I do see the benefits of having the default abi embedded into the CHOST |
41 |
tuple but migrating to it may be quite painful. |
42 |
|
43 |
-- |
44 |
Regards, |
45 |
Markos Chandras |