Re: dpkg: emdebian.org and other machines patched for armhf support
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
Reply to: