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

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

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:

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

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

Reply to: