[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#594179: dpkg armhf patch acceptance status?



+++ Steve Langasek [2011-02-18 17:36 -0800]:
> > * 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.

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). 

> 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 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). 

> 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?

This is the nub of the practical problem.

> 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. :(

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? 

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).

However, equally, it's taken a really long time to get this far, and
if we made a reasonable effort to get GCC people to agree with
guilem's view of the world, but failed, then I'm happy that the
expediency of the new tuples is justified. 

Wookey
-- 
Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM
http://wookware.org/


Reply to: