Re: Triplet for ARM Linux HardFP ABI, again

[Andrew Stubbs <ams at codesourcery dot com>]

On 21/02/11 10:12, Guillem Jover wrote:
> This was already discussed in this list some time ago [0]. But it came
> up again when restarting the discussion for the proposed new armhf port
> for Debian.
>
>    [0]<http://gcc.gnu.org/ml/gcc/2010-07/msg00179.html>
>
> My arguments for why a distinct triplet is needed can be found in [1],
> it's a big long though. Most of the points there revolve around the
> fact that we rely on the toolchains as configured by_default_  to
> produce the expected output targetting a concrete architecture, it
> also has implications for the file system paths.
>
>    [1]<http://lists.debian.org/debian-dpkg/2011/02/msg00039.html>
>
> It seems from reading the past discussion on this list that the main
> objection was that the triplet should not be used to decide what
> floating point ABI to use in gcc. No problem with that!

Up front, let me say I disagree with the previous finding that the 
triplet isn't the right place for this kind of thing. It's clear to me 
that there's plenty of prior art here, and it would work for us very 
nicely, thank you very much. That said, there are down-sides to 
target-triplets (not least that once you've chosen one, you find 
yourself stuck with it for backward compatibility, even after it makes 
no sense any more), and many people seem to believe it would be better 
if they had never been invented, so .....

I fail to see how abusing the OS/ABI field is any better than abusing 
the vendor field?

The patch you posted is surely just the tip of the iceberg - there are 
thousands of packages in Debian, and any one of them might need 
adjustment to cope with this change.

When I proposed a new triplet before, in the thread you referenced 
above, I proposed having an 'official' name that everyone would agree 
on. That would have been disruptive. Your triplet would be unofficial, 
so I would say it would be hard to justify all that disruption. In the 
worst case, third parties would start to use your unofficial triplet 
inconditionally, and would need fixing up to work with anything that is 
not Debian.

In July's thread, it was decided (sort of) that the compiler should not 
choose its (micro-)configuration based on the triplet. I didn't really 
agree with that, but there it is. You've decided to stick with that, and 
have the triplet influence only your build-system. Surely that's exactly 
what the 'vendor' field is for? It seems like (it has to be) a 
vendor-specific configuration to me.

Adjusting the vendor field should not break any of those thousands of 
packages (although, no doubt there'll be the odd one or two). It will 
give you your differentiated pathnames. It will tell your build-system 
what to do. Why do it the hard way if there is no advantage?

Andrew