On 12/29/2013 05:33 PM, Markos Chandras wrote:
On 12/29/2013 10:19 PM, Anthony G. Basile wrote:
On 12/29/2013 05:13 PM, Markos Chandras wrote:
On 12/29/2013 09:52 PM, Anthony G. Basile wrote:
On 12/29/2013 04:48 PM, Markos Chandras wrote:
On 12/29/2013 09:48 PM, Michał Górny wrote:
Dnia 2013-12-29, o godz. 16:40:08
Joshua Kinard <[email protected]> napisał(a):
On 12/28/2013 5:58 PM, Michał Górny wrote:
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}"
[...]
Matt can probably vouch for this better, but the only two ABIs
affected by
this are n32 and n64. mips[el]-unknown-linux-gnu implies a 32-bit
big/little endian CHOST, which means the o32 ABI.
mips64[el]-unknown-linux-gnu means either n32 or n64. So no change
should
be needed for o32-based installs.
Just to be clear:
profiles/arch/mips/mipsel/mips64el/multilib/make.defaults:
CHOST="mips64el-unknown-linux-gnu"
[...]
CFLAGS_o32="-mabi=32"
CHOST_o32="${CHOST}"
CFLAGS_n32="-mabi=n32"
CHOST_n32="${CHOST}"
CFLAGS_n64="-mabi=64"
CHOST_n64="${CHOST}"
So in this case, o32 actually uses mips64el-unknown-linux-gnu, unless
I'm missing something.
Yes all 3 ABIs use the same tuple.
I think people are missing Mike's point from earlier, which is that
tuples label toolchains and a toolchain can support multiple abis. So
for example, what would one do on a system which simultaneously has o32,
n32 and n64? -gnuabi32n32n64 looks pretty crazy.
There is only one default ABI, so the toolchain should be named after
that. But that does not mean the toolchain can't build for different ABIs
No because that would confuse a toolchain which only supports n32 with
one that supports o32/n32/n64.
Ah fair point
Anyhow, Michał response is heading in
the right direction where we'd have to use multiple tuple on multilib
system support more than one lib. I'm still not sure where this will
land us with respect to gnuconfig and other tuple parsing tools that
bring in their own assumptions.
I would guess that if debian is using the -gnuabin32/64 suffix and it
works for them, then such tools would already understand such tuples.
Or their maintaining lots-o-patches which is what starts to happen when
you deviate from standards. Anyhow, we should talk to them and see.
--
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail : [email protected]
GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA
GnuPG ID : F52D4BBA
