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

Re: armhf multiarch tuple




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
compatibility.
For a concrete example of such mixing being useful mpthompson has been using
chroots with such a mixture to get our "armhf for Pi" port going thereby avoiding
the massive mess involved in trying to bootstrap a debian architecture from
scratch (we also have a script to check the resulting binaries are free of armv7
code in case any slips through).

Obviously such an arrangement will mean that Pi users will have to be careful
what repos they use but that is hardly a new issue. If you use an older x86
family CPU you have to be careful not to use binaries built on ubuntu.

but debian architectures never specified a CPU
instruction set version to date, and I don't see why armhf is
different in that regard.
I agree here. The instruction set version (which defines the minimum CPU
you need) and the ABI (which defines what binaries will work together)
are and should remain orthoganal issues (with the obvious exception that
some abis will force certain minimum instruction sets).


Reply to: