On 7 December 2010 18:35, Paul Brook paul@codesourcery.com wrote:

...

In essence, I would like to express my objection in having the same triplet for both softfp and hard ABIs. I know upstream (ARM) objects, but IMHO they just haven't done the extensive compiling I have and didn't consider the problems (I doubt anyone else has built ~8000 packages for a hardfloat port).

As the relevant upstream maintainer I'll confirm this objection.  In the past gcc used to try and guess which config to use based on variants of the triplet. In practice this caused more problems than it solved, especially when you have a single toolchain that can target multiple variants.

If you want different triplets then I suggest you use the vendor field. e.g arm-debian_armel-linux-gnueabi and arm-debian_armhf-linux-gnueabi.

Which is exactly what I am doing. You are right I should be more specific. Right now, armhf uses arm-hardfloat-linux-gnueabi -which as was suggested here uses the vendor field. It works fine, in truth, only a handful of packages break with the vendor field and the fix is trivial.

What was suggested to me was that the vendor field should *NOT* be used and a single arm-linux-gnueabi should be used for both softfp and hard ABIs. I'm sorry but especially in the case of compilers and in particular cross-compilers, this just does not work. Unless there is another way of OS (and ABI) detection, like the DEB_HOST_ABI fields, there is no way to know which ABI to compile from.

So, my objection is in not keeping the arm-hardfloat-linux-gnueabi triplet. I did not suggest a different triplet altogether, just the ability to use the vendor field and thus in essence make a different triplet -but not too different.

Konstantinos