On 19 March 2012 21:48, Konstantinos Margaritis <konstantinos.margari...@linaro.org> wrote: > On Sun, 18 Mar 2012 23:27:17 +0000 > Mans Rullgard <mans.rullg...@linaro.org> 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 _______________________________________________ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
