[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


Reply to: