> 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 -- To UNSUBSCRIBE, email to debian-arm-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/201007082358.11852.p...@codesourcery.com
