Plan for changing the binary toolchain to 4.7 and hardfloat

Michael Hope michael.hope at
Mon Mar 19 21:15:05 UTC 2012

On 19 March 2012 21:48, Konstantinos Margaritis
<konstantinos.margaritis at> wrote:
> On Sun, 18 Mar 2012 23:27:17 +0000
> Mans Rullgard <mans.rullgard at> wrote:
>> FWIW, Gentoo has been using arm-hardfloat-linux-gnueabi for hardfloat
>> configurations ever since gcc started supporting it.  That's of course
>> not a triplet, strictly speaking.
> Also fwiw, I have been assured from Gentoo developers that they will change their triplet to arm-linux-gnueabihf as soon as upstream adopts it.
> I find the situation sad as well, since Linaro has been pushing for this triplet (at least the OCTO team and me personally for more than a year), and not having full support from within Linaro with regards to this matter is quite depressing. And I have to say, especially one of the arguments (Windows storage issue) should be irrelevant for a Linux problem.

I'm happy to make changes.  Here's what I need:
 * Runs on the top four Linux desktop distros (plus RHEL)
 * The state of the art in performance (hard float + A9)
 * Support for one target distro
 * Installable by an unprivileged user
 * No feature regressions.  If we change triplets, we change it once

Here's what I'd like:
 * No hard break in compatibility
 * Usable across a product range, including non Cortex-As
 * The fastest Cortex-A15 configuration
 * Not prohibit dropping in a Fedora or other ARMv7 hardfloat sysroot
 * No surprises.  The same command should give the same output, no
matter who supplies it

which means:
 * Multilib for the non-ABI variants
 * A armv4t libgcc for u-boot
 * Enough support so an end user can drop in a softfp sysroot and use it

I'd prefer not to invalidate all the documentation out there by having
a hard break in triplet.  Perhaps the default is gnueabihf and we
provide gnueabi symlinks?  This breaks the rule of no surprises as
there'd be a difference in behaviour between the Debian and Linaro
binary builds and probably loader name issues.

Note that the binary toolchain is a product compiler that inherently
has a sysroot.  The needs are different to distro native compiler or a
Debian cross-develop setup.

The upstream scripts do not recognise gnueabihf.  Our policy is to be
equivalent to upstream and have no long term (> 6 month) patches.  I'm
happy to take a patch providing someone commits to getting it upstream
in a reasonable time.

I've updated the wiki page with the new arguments.  Linaro should move
as one and use the same best practice across all groups.  I'm happy to
take the patches and risk but driving this change is not in
toolchain's mission.

-- Michael

More information about the linaro-dev mailing list