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

Re: armhf multiarch tuple

+++ Steve McIntyre [2012-04-17 17:01 +0100]:
> On Tue, Apr 17, 2012 at 10:53:47AM -0500, Jonathan Nieder wrote:

> >Based on the "Questions regarding armhf port for Raspberry Pi" thread,
> >I think some people believe that ARMv6+VFP binaries using the hard
> >float ABI should be binary compatible with Debian armhf (and in
> >particular it should be possible to swap in packages built that way
> >one at a time and still have a working Debian system on an ARMv7+
> >machine).
> >
> >Is that assumption wrong? 
> They'll be upwardly-compatible (i.e. they'll work on v7), but not in
> reverse. armhf is explicitly defined to be ARMv7+, using VFPv3-D16 (no
> Neon). That's standardised across distros too.

To be explicit, with a multiarch view of the world, the triplet
defines the ABI, but not CPU instruction set. That's a distro-choice
for whatever is reasonable (and they've all agreed on v7 for now
except pi-people), in the same way that debian i386 is built for an
i586 CPU minimum now, rather than i486, and debian armel is currently
built for v4t but is likely to move forward to v5 at some point.

So binaries built for v6 VFP2 and v7 VFP3-D16 are both
'arm-linux-gnueabihf' and will interoperate so long as your CPU can
actually run them. In practice this gives you 'newer CPUs only' binary

The instruction set version should be managed with HWCAPS so that dpkg
could tell you if you tried to install stuff that wasn't going to run,
but we haven't done the work to make that actually work.

It's beginning to look like it might be a good idea to push that

This would appear to mean that I disagree with Steve on what the
definition means, but debian architectures never specified a CPU
instruction set version to date, and I don't see why armhf is
different in that regard.

Principal hats:  Linaro, Emdebian, Wookware, Balloonboard, ARM

Reply to: