Re: armelfp: new architecture name for an armel variant
> The set of incompatible ABI options (as opposed to instruction set
> options) we have is:
You missed one. This should be LE/BE32/BE8.
BE32 and BE8 are only compatible at the object file level, not at the
application/shared library level.
For those following at home BE32 is conventional big-endian, and includes
things like xscale. BE8 is little-endian code and big-endian data, and
includes most armv6 or later hardware.
> hard-float/soft-float calling convention
> and maybe losing the existing 'eabi' moniker would cause too much
> trouble, as would having an alias for the existing EABI, soft-float
> port, so that leaves us with:
> armel arm-linux-gnueabi
> armelhf arm-linux-gnueabihf
> arm arm-linux-gnu
My guess is that most things are setup to match the target triplet against
"arm*-*eabi". Adding extra bits to the end will likely break this.
Requiring these to be different target triplets is purely a dpkg limitation.
In other circumstances it's common for a single toolchain to support all of
the above (and more). I recommend [ab-]using the manufacturer field. This is
defined to have no meaning, so seems like a logical solution for a Debian