dpkg: emdebian.org and other machines patched for armhf support
markos at genesi-usa.com
Tue Dec 7 16:58:54 UTC 2010
On 7 December 2010 18:35, Paul Brook <paul at 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
> 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
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.
More information about the linaro-dev