Hi Guillem, Thanks for letting us know your thoughts. On Fri, Feb 18, 2011 at 11:13:11AM +0100, Guillem Jover wrote: > * 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 > `--- But then we also have biarch and triarch toolchains in the archive, where the host triplet doesn't change at all and instead gcc multilib is used to designate what ABI you want. The upstream argument seems to be that armel/armhf isn't "cross-compiling", it's merely ABI selection within an architecture. This sort of "cross" compiling doesn't yield binaries that can't be run on the build machine, and therefore most of the cross-compilation logic in autotools doesn't apply. (Never mind that upstream does not apply this reasoning consistently; the fact that there's precedent means it's going to be harder to argue the point with them.) > * The remaining problem at least for multiarch is the use of more > specialized cpu names for the i386 triplets, i486-linux-gnu on Debian, > which might change depending on the base instruction set to support, > for example i686-linux-gnu on Ubuntu. > Due to #611741, it already crossed my mind (but removed it from the > list of solutions before sending the reply as at the time it seemed > slighly preposterous just to fix the divergence with Ubuntu) that we > should switch back our i386 arch to use i386 as the base cpu name for > the triplet (i386-linux-gnu) in the same way we use it in other > arches, like on arm where we use arm-linux-gnu instead of something > like armv4tel-linux-gnueabi, for example. (I mentioned this already to > Steve and Raphaël on some private conversation.) The challenge, as Matthias points out, is that these triplets are already so entrenched and there is so much software that handles x86 specially - even if incorrectly! - that it's prohibitive to switch back to i386-linux-gnu as our triplet because of all the re-porting work we'll have to do to get properly functioning packages on x86. > Package build systems might be matching against stuff like > arm*-*-linux-gnueabi, so it might require changes to match on -gnueabi* > instead, but is more immediate, and not like propagating config.guess > all over the place, which we should not need as debian/rules should > be passing --build to configure anyway, and config.sub can already > canonicalize something like arm-linux-gnueabihf by way of the current > patterns. Yes, package build systems do match on stuff like arm*-*-linux-gnueabi; my understanding is that this was the pattern match that was propagated when EABI was introduced on ARM, and as a result there's a fair amount of software that will misbuild for eabi+hf if we go with -gnueabihf. So basically, it's the same problem we have as for switching to i386-linux-gnu on i386, just on a different set of software in the archive. How do we locate the software that will be affected by such a change? I think this has proven non-trivial in the past. But ultimately that's for the porters and the GCC maintainers to decide whether they're happy with that answer; it's an aside to the main point of my mail, coming up below. :) > > > 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, which > should not change incompatibly for a given Debian architecture, or we > are screwed anyway. So I don't see that it buys us much. The underlying intent of the tuples proposal is that we stop pretending that GNU triplets provide a valid global one-to-one mapping to ABIs, because we know from several concrete, high profile examples that this is not true. You have proposed a patch that Matthias has said "looks ok", but if he adds it to the Debian/Ubuntu gcc, that only solves the problem for Debian and Ubuntu. Multiarch is intended as a cross-vendor standard, fixing the FHS's inadequate lib<qual> directories and providing binary interoperability for anyone choosing to implement it. How can we achieve that if we're using strings in our paths that are dependent on distro-specific patches? Do we expect to tell other implementors they have to use our GCC? The multiarch tuple proposal would externalize this problem by establishing a central, standard, one-to-one mapping between ABIs and strings *for this precise purpose*. I'm perfectly happy for Matthias to accept your gcc patch in parallel so we establish a distinct GNU-ish triplet for armhf, but unless this can get upstreamed, I don't think it solves the problem we have with using GNU triplets for multiarch paths. Do you agree, or do you still think multiarch should continue to be dependent on GNU triplets, which - as we've seen - are not managed in a consistent manner? > 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). Given that there is no consensus that this is even a bug to be fixed, I am not content to have multiarch blocked indefinitely on getting triplet fixes propagated upstream; nor am I happy to have multiarch paths tied to distro-specific implementation details. Are you going to do the heavy lifting to get these changes accepted by GCC upstream? How long do you think that will take, and at what point would you decide that you're not getting anywhere and fall back to diverging from upstream for multiarch? I've rather firmly committed to getting initial multiarch support landed in the 11.04 Ubuntu release. If we can (collectively) get our decision made on the path selection *now*, that's achievable - and we can be rid of ia32-libs from Debian (unstable) and Ubuntu within a year, and we can bring armhf up as the first multiarch-from-the-start port in Debian. If we instead let ourselves get drawn into open-ended discussions trying to persuade GCC upstream that we're right about triplets and they're wrong, it may be years longer before we see any multiarch implementation at all. Remember that we were discussing multiarch before sarge was released - I don't want to still be discussing it after wheezy is out. :( Thanks, -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slangasek@ubuntu.com vorlon@debian.org
Attachment:
signature.asc
Description: Digital signature