Re: dpkg armhf patch acceptance status?
Loïc's latest post drew my attention back to this thread, where I see I had
this message flagged for follow-up:
On Fri, Sep 10, 2010 at 09:35:24AM +0200, Goswin von Brederlow wrote:
> > I realize this is ideal, but:
> > - there's been very strong upstream pushback on this, asserting that this
> > is the correct triplet to use for both arm calling conventions, so if we
> > require a distinct triplet for armhf (instead of using the vendor field),
> > that's going to block any armhf port for quite a while (possibly
> > indefinitely)
> > - armhf was not the sole motivation for the proposal to define neutral
> > architecture names; x86 was already a problem because of the changing
> > triplets depending on which level of instruction set compatibility is
> > targeted. *Both* of these examples show that GNU triplets are not
> > defined in a way that they map directly to what we need for multiarch, so
> > it's best to explicitly define our mapping externally.
> > So even if you persuaded the upstream toolchain folks to specify a new
> > triplet for armhf after all, I think we should still go ahead with a
> > separate name mapping table for multiarch.
> Note that uclibc also suffers this problems. x86_64-linux-uclibc is in
> no way unique as different uclibc compile options create different ABIs
> all with the same tripplet.
We have a draft proposal for tuples to use in the filesystem paths for
uclibc is included in the design, with a single identifier of 'uclibc'. We
probably need to have a better definition here. Where is the right place to
raise this point for discussion in Debian? Should I bring this up on the
debian-embedded list? Are there other stakeholders who would have input
regarding the array of available uclibc ABIs and how to specify these?
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/