On Mon, Feb 21, 2011 at 02:22:44AM +0000, Wookey wrote: > > 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. > I know little of x86 world, but are we sure this is more work than the > fixing-up we'll need to do in many packages to properly deal with > multiple available ABIs within a toolchain, and making the new > MAtuples be used correctly everywhere? (especially when > cross-building, for both matters). "multiple available ABIs within a toolchain" is not a problem that has to be solved on x86 today, so yes, it is more work. On x86 we do have at least one tuple identifier for each ABI - we just have the problem that we have /too many/ of them available on x86. But while multilib toolchains are definitely of interest on x86 (-m32/-m64), each of these ABIs also have a distinct tuple associated with them (x86_64-linux-gnu, i<n>86-linux-gnu). > > 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 agree that this establishment of a generic FHS multiarch library > path standard is the right thing (TM), and that it's no good if it > can't be done upstream . But equally Guillem is right that > ABI-sepecific triplets could do that job too (and with less change to > existing practice overall). Multiarch is a significant departure from existing practice one way or the other. I think the question of whether we maintain our ABI string list as a delta against GNU triplets or as an entirely separate standard is really quite a minor detail in comparison. > I guess I missed the first 3-odd years of this debate. I'm assuming we've > already tried reasonably hard persuading the GCC people on this point? In the x86 case, it's not something that GCC people can fix. The overloading of GNU triplets on x86_32 is now a well-entrenched practice throughout the community, and neither they nor we can fix by fiat the consequences of changing our triplet - only by a lot of hard work. In the armhf case there was an upstream mailing list discussion, from which the only emerging consensus (to the extent we can say there was one) was that the official GNU triplet should stay the same. This mailing list discussion informed the BoFs we had at DebConf about multiarch tuples, and I think it qualifies as "tried reasonably hard". It's hard enough for my purposes, because I'm not out to try to dictate policy to the GCC maintainers, so when they say that's not what triplets mean, I greatly prefer finding a path of lesser resistance. I thought we had that with the multiarch tuples proposal, but maybe not. :/ > Unless the feature of being able to separately specify toolchains > (triplets) and ABIs (tuples) is important (and it may be for > biarch/triarch arches, but I'm not yet convinced), then given the > extreme similarity of tuples and triplets, it does seem like > ABI-specific triplets would be a 'better' solution to this problem > than inventing a new set; and in general Debian likes to go for the > technically-best solutions even if it takes longer. (Multiarch in > general is an example of this). I don't see either of these to be technically better or worse. The fact is that we are going to *have* to document multiple points where our directory strings do not follow naturally from the existing array of GNU triplets; and that documentation needs to be maintained in a readily consumable fashion. Given those constraints, I don't think that using a modified set of GNU triplets is any better than creating new strings from scratch. -- 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