Re: armelfp: new architecture name for an armel variant
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
Reply to: