Re: Bug#594179: dpkg armhf patch acceptance status?
+++ Guillem Jover [2011-02-18 11:13 +0100]:
Guillem makes some good points about how GNU triplets should (and once
did) represent ABIs, and that if they still did, dpkg (and everything
else) could use them as the definitive ABI-indicator. He's quite
right.
_Something_ has to stand as nomenclature for the ABI. It could equally
well be GNU triplets or Multiarch Tuples. I'm quite happy for either
to be used. Multiarch directories could use triplets under those
circumstances and there would be no need for the new tuples.
But it is also the case that a given toolchain can produce binaries of
different ABIs, so there is logic in the GCC argument that the triplet
denotes a toolchain, not (necessarily) an ABI. (e.g arm-linux-gnueabi
toolchain can produce armel and armhf binaries (and in fact there are
more incompatible ABIs it could spit out, but we're not trying to make
distros out of those).
It makes sense to me that, these days, a triplet represents a
toolchain, and an MAtuple an ABI. If there was a 1-1 mapping between
these things then triplets would suffice, but there isn't.
So it seems to me, that we either have to persuade GCC to go back to
one triplet per ABI or we need to adopt the proposed Tuples.
It is logically neater in many ways to go back to one-triplet-per-ABI,
but like Steve, I'm not optimistic about this being ultimately acceptable
to upstream or that it could be done in a sensible period of time.
Starting again with a properly defined list and some rules about new
identifiers lets us get it right this time, and arrange for it to stay
right in the future.
So what happens if we do this? Let's look at some examples mentioned
so far:
> * I think it's important to be able to consistently support co-installing
> different default cross-compilers for different ABIs which would
> otherwise share the same triplet. And while we could avoid the problem
> for multiarch libraries co-installations by using the multiarch tuples,
> we would not be able to avoid it for the cross-compilers.
This is true, but in fact the arm-linux-gnueabi and arm-linux-gnuhf
toolchains would be the same apart from their libgcc and default options
(spec file). A multilib build of this toolchain, supporting both
options, would work for targetting both ports, but we do still lack a
good way of switching spec files to change the default target (which
would be useful for all sorts of reasons).
> * The assumption that each GNU triplet denotes a different ABI is so
> entrenched in the GNU build system, that we have things like the
> following all over the place to properly support cross-building:
>
> ,---
> ifeq ($(DEB_BUILD_GNU_TYPE), $(DEB_HOST_GNU_TYPE))
> confflags += --build $(DEB_HOST_GNU_TYPE)
> else
> confflags += --build $(DEB_BUILD_GNU_TYPE) --host $(DEB_HOST_GNU_TYPE)
> endif
> `---
>
> This would not hold true any longer if we didn't use a unique triplet
> per arch, and would thus break in quite annoying ways.
Yes, this is potentially a pain in the bum. We need to select a
toolchain (which could be 'arm-linux-gnueabi' for both arm port
targets, but with different default options and a different default
linker and include paths). I haven't yet worked out how those will be
selected, as currently they are built-in to the cross-compiler and
referring to it by name sets them implicictly.
debian/rules has access to the -a<DEB_HOST_ARCH> which allows the
necessary discrimiation, and automatically supplies the
/etc/dpkg-cross/cross-config.<DEB_HOST_ARCH> autoconf values, which
may be sufficient, along with config.guess.
There are a lot of instances of -L /usr/<DEB_HOST_GNU_TYPE>/lib which
need fixing for multiarch anyway, so even if we have unique GNU
triplets, work will be needed in lots of packages to make
cross-building work again. Anything which already relies on default
compiler paths should work fine.
If using non-unique toolchain triplets, we need a robust mechanism for
host ABI selection within the multilibs available.
> * Ignoring the bi-directional 1:1 mapping would be a PITA, as it implies
> not being able to automatically bootstrap dpkg on a new port or
> dpkg package builds on foreign distros. The former is annoying but not
> done frequently, the latter is going to be a problem for each non-dpkg
> based distribution, as they'll have to bootstrap dpkg on each arch
> where dpkg is built anew. It ends up being a matter of off-loading the
> knowledge of the arch and build system from the dpkg/gcc combo to the
> porters/maintainers, which seems rather unappealing.
I don't think I understand this point. Who are these people that
build dpkg on non-dpkg distro, and why will they have harder
bootstraping?
> > > 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).
>
> Oh, but I think I just did. :) Also given the above I don't think it
> makes sense to invent a new set of tuples, the triplets should work
> just fine. In addition those tuples end up relying partly on the
> definition of the ABI the default gcc has for a given target,
Well, we need to be able to specify the ABI (and thus paths/gcc options) to
use. That has traditionally been done with the triplet causing gcc
defaults to be used, but it can just as well be done in an
upstreamable and cross-distro way using LSB-certified MAtuples. Either
could work - which is easier, or otherwise provides overall benefit?
> > > 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.
On in the spec file.
> > 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.
>
> Given the above conclusion, that the GNU triplets must be already unique
> per arch and cannot arbitrarily change ABI or it'd break stuff, I don't
> really see the point in switching the internal representation, because I
> don't really see the point in the multiarch tuples, when the GNU triplets
> seems to do the job just fine (modulo the armhf and i386 issues, which we
> should just fix).
This pretty-much boils down the issue. dpkg needs to use a unique and
reliable internal representation. Can that carry on being/go back to
being triplets, or do we have to use the MAtuples?
Wookey
--
Principal hats: Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/
Reply to: