Re: Bug#594179: dpkg armhf patch acceptance status?
Hey
Trying to kick the dust a bit as having the triplet "in the air" is
kind of an unhappy situation for armhf :-)
On Wed, Sep 08, 2010, Guillem Jover wrote:
> We currently need something like this in dpkg-dev because the mappings
> need to be bidirectional, as dpkg-dev needs to be able to convert
> from GNU triplet to Debian architecture and the other way around.
>
> Steve wondered why this is the case, and that's because for
> cross-compiling purposes dpkg-architecture infers the host architecture
> from the CC environment variable through the -dumpmachine option.
> Chaning this is possible but, would break a current way of
> cross-compiling which has been around for a long time.
So this use case is "CC=arm-linux-gnueabi-gcc dpkg-buildpackage" and it
just guesses the -a flag that you should have set?
> The toolchain has the same triplet for binary incompatible producing
> objects, which seems like a bug/misfeature to me, and that's one of
> the assumptions dpkg-dev has relied on, in the same way as multiarch
> when deciding to use the triplet as a unique token for the installation
> directories.
You describe this as a bug/misfeature, that might be true but I don't
think we can challenge this usage of triplets in the upstream
toolchain, and multiarch is moving to having its own tuples instead now
(http://wiki.debian.org/Multiarch/Tuples).
> 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.
Even if we could co-install them, I'm not sure how
/some-armel-path/arm-linux-gnueabi-gcc and
/some-armhf-path/arm-linux-gnueabi-gcc could helpfully be installed on
the same system :-/
It's a real limitation of the upstream toolchain.
> Also that also happens with biarch, you can produce i386 binaries from
> an x86_64 toolchain, yet they both have their own triplet.
Yes but x86 goes to the other extreme, with separate triplets for
compatible ABIs ({i386,i486,i586,i686}-linux-gnu); the fact is the
triplet is not a good ABI specifier.
> 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. But if this is not going
> to happen, and thus the assumptions dpkg-dev is making have been just
> wrong, then I'd rather drop the bidirectional mappings, and be done
> with it. This will need careful consideration though, as it's breaking
> a current interface, but something that could be done for dpkg 1.16.x.
Having a separate triplet (not using the vendor field) like e.g. lpia
would mean a lot of pain IMO, and we'd have to fix many packages to
cope with it, including reaching out to upstream etc. It was pain for
lpia for sure.
We could have an additional set of preprocessor macros which dpkg
checks for to decide which Debian architecture we're talking about; the
the would only be done if there is more than one architecture using the
same triplet in dpkg tables. This alone is a bit fragile though, as it
means that if a new ABI is introduced to an existing triplet and is not
immediately added as a new dpkg architecture, then people might be
picking the wrong dpkg architecture when using a toolchain defaulting
to thenew ABI.
I wonder whether it would be a good idea to use multiarch tuples
internally; dpkg would still have to map to/from GNU triplets, but it
would force implementors to think about their ABI. I am not sure how
we can ensure that we've mapped to the right tuple though. Neither am
I sure that the multiarch tuples are frozen already, so it might be too
early for that either.
Bye
--
Loïc Minier
Reply to: