Re: armelfp: new architecture name for an armel variant

[Paul Brook <paul@codesourcery.com>]

> The set of incompatible ABI options (as opposed to instruction set
> options) we have is:
> OABI/EABI
> big-endian/little-endian

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 
specific hack.

Paul