On Wed, Sep 08, 2010 at 11:40:13AM +0200, Guillem Jover wrote: > This also causes issue with not being able to have installed two > cross-toolchains for say armel and armhf as they share triplet, > although you can use the armel toolchain with few options to build for > armhf, but then you'd need to specify those as part of the CC variable. > Also that also happens with biarch, you can produce i386 binaries from > an x86_64 toolchain, yet they both have their own triplet. > I'm just wondering if this is also the case for mips triarch, or do > those have each their own triplet, and is only arm that has this > issue? mips have distinct triplets for each of their archs, yes. > Anyway, ideally I'd rather see this addressed by giving armhf a real > triplet, which would also make multiarch life way easier as there'd not > be any need to define an artificial set of neutral architecture names > to be able to place objects in the file system. I realize this is ideal, but: - there's been very strong upstream pushback on this, asserting that this is the correct triplet to use for both arm calling conventions, so if we require a distinct triplet for armhf (instead of using the vendor field), that's going to block any armhf port for quite a while (possibly indefinitely) - armhf was not the sole motivation for the proposal to define neutral architecture names; x86 was already a problem because of the changing triplets depending on which level of instruction set compatibility is targeted. *Both* of these examples show that GNU triplets are not defined in a way that they map directly to what we need for multiarch, so it's best to explicitly define our mapping externally. So even if you persuaded the upstream toolchain folks to specify a new triplet for armhf after all, I think we should still go ahead with a separate name mapping table for multiarch. Cheers, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature