+++ 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/ -- To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110221015244.gm22...@dream.aleph1.co.uk