Hi there. Over the next three months both GCC 4.7 and Ubuntu 12.04 'Precise' are coming out. We'll switch over to these pretty quickly which will affect our internal testing and anyone using the binary toolchain.
The changeover plan including dates, details of what's happening, and backwards compatibility is at: https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Comments and concerns are welcome,
-- Michael
On Fri, Mar 16, 2012, Michael Hope wrote:
https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Is there a separate plan for gcc-4.5 deprecation in source releases?
The triplet situation is sad; is there any hope that we fix this upstream?
On 17 March 2012 08:10, Loïc Minier loic.minier@linaro.org wrote:
On Fri, Mar 16, 2012, Michael Hope wrote:
https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Is there a separate plan for gcc-4.5 deprecation in source releases?
Yip, I'll send an email on that today.
The triplet situation is sad; is there any hope that we fix this upstream?
It's not for Linaro to change but for Debina/Ubuntu. The upstream canonical triplet is arm-linux-gnueabi for any configuration including soft or hard float. We talked about this at a cross distro session and Steve McIntyre was going to push some of the first steps.
-- Michael
On 18 March 2012 19:23, Michael Hope michael.hope@linaro.org wrote:
On 17 March 2012 08:10, Loïc Minier loic.minier@linaro.org wrote:
On Fri, Mar 16, 2012, Michael Hope wrote:
https://wiki.linaro.org/MichaelHope/Sandbox/BinariesMigration
Is there a separate plan for gcc-4.5 deprecation in source releases?
Yip, I'll send an email on that today.
The triplet situation is sad; is there any hope that we fix this upstream?
It's not for Linaro to change but for Debina/Ubuntu. The upstream canonical triplet is arm-linux-gnueabi for any configuration including soft or hard float. We talked about this at a cross distro session and Steve McIntyre was going to push some of the first steps.
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.
On Sun, 18 Mar 2012 23:27:17 +0000 Mans Rullgard mans.rullgard@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.
Regards
Konstantinos
Michael, me too. Can you talk to Steve McKintyre and Konstantinos about this? We've spent the last 12 months trying to get alignment / agreement across all of the distributions on this. arm-linux-gnueabihf is the least worst, agreed option. Dave
On 19 Mar 2012, at 08:48, Konstantinos Margaritis wrote:
On Sun, 18 Mar 2012 23:27:17 +0000 Mans Rullgard mans.rullgard@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.
Regards
Konstantinos
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
On 19/03/12 08:48, Konstantinos Margaritis wrote:
On Sun, 18 Mar 2012 23:27:17 +0000 Mans Rullgardmans.rullgard@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.
Upstream's position has been that what Gentoo was doing is the preferred solution, or even have no change to the triplet at all. In both cases, software that cares should use a configure script to detect the ABI (most won't care: compilers are good like that).
Of course, in the real world it turns out that having a unique identifier that everyone agrees on is a good thing too, so I understand the distros' decision to create a defacto standard, but I don't know if it will go upstream as such.
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 think the "correct" solution to this would be to have the binary toolchain built in a multilib configuration that supports both softfp and hardfp, and provide aliases for both triplets that configure the right setting, but that requires more build, test, and install effort and trickery, and it's not clear how much benefit there would be.
I don't really understand why the compiler name can't just be changed to match the ABI change though?
Andrew
On 20 March 2012 01:42, Andrew Stubbs andrew.stubbs@linaro.org wrote:
I think the "correct" solution to this would be to have the binary toolchain built in a multilib configuration that supports both softfp and hardfp, and provide aliases for both triplets that configure the right setting, but that requires more build, test, and install effort and trickery, and it's not clear how much benefit there would be.
It's not trivial with the current tools. The loader name changes as well but this isn't critical - we don't need to support more than one distro, just not lock out other uses.
I don't really understand why the compiler name can't just be changed to match the ABI change though?
Upstream GCC recognises arm*-*-linux*-*eabi and not *eabihf. Other packages may be the same.
-- Michael
On 19 March 2012 21:48, Konstantinos Margaritis konstantinos.margaritis@linaro.org wrote:
On Sun, 18 Mar 2012 23:27:17 +0000 Mans Rullgard mans.rullgard@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
-
Andrew Stubbs -
David Rusling -
Konstantinos Margaritis -
Loïc Minier -
Mans Rullgard -
Michael Hope