Re: dpkg armhf patch acceptance status?
Steve Langasek <vorlon@debian.org> writes:
> 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,
Note that uclibc also suffers this problems. x86_64-linux-uclibc is in
no way unique as different uclibc compile options create different ABIs
all with the same tripplet.
I filed a wishlist bug against dpkg-architecture to please provide
DEB_HOST_ABI / DEB_BUILD_ABI and to start giving that as
DEB_HOST_GNU_TYPE / DEB_BUILD_GNU_TYPE initialy. Ports where this is
insufficient can then extend the table to give a unique value.
MfG
Goswin
Reply to: