On Thu, Jul 08, 2010, Wookey wrote: > The first thing I've found is that whilst we can build for > --mfloat-abi=hard there is no macro set by GCC to detect this state.
For the record: https://bugs.launchpad.net/gcc-linaro/+bug/602745 > manufacturer/vendor doesn't really supply useful information these > days and is usually none or omitted. Yes, it's kind of optional free form text > OS has been overloaded to include the ABI since the OABI ('gnu') EABI > ('gnueabi') split. This isn't very pretty, but despite thinking about > it for a while I haven't had any better ideas. I don't think that > re-purposing the vendor/manufacturer field would really work, and > adding a 5th field would also be a lot of pain (there are a lot of > regexps in a lot of software to fix up). But if anyone does think it's > a good idea then I don't mind taking a look at the practicalities. Please, let's not use the last field; there is not only the default target of the toolchain, there is also the toolchain itself. An arm-linux-gnueabi toolchain can target both soft and hard float calling conventions, so a single triplet. It would be perfectly fine to use this triplet for toolchains/products built using either the soft or the hard float calling conventions. The only issue is ... Debian's constraints. Debian wants different triplets for dpkg and other reasons (e.g. Multiarch). Debian is a vendor and can use the vendor field. Upstream software should ignore the vendor field, unless they know it. It would be odd for us to invent an ABI which upstream doesn't know about (upstream knows about arm-linux-gnueabi) and force them to use it. The vendor is really the place for extensions IMO; I tried capturing this earlier piece of the discussion on the wiki page. wiki.debian.org/ArmHardFloatPort#Triplet -- Loïc Minier -- 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/20100709143740.gc14...@bee.dooz.org
