Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On Sun, 18 Mar 2012 23:27:17 + Mans Rullgard 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-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
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 + > Mans Rullgard 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-...@lists.linaro.org > http://lists.linaro.org/mailman/listinfo/linaro-dev ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
[ACTIVITY] 12th - 17th March
* Linaro GCC Spun release tarballs for Linaro GCC 4.5 and 4.6. Launched the build and test runs. When those completed, briefly checked the results, and launched the package build tests and benchmark runs. Continued trying to figure out how my NEON 64-bit immediates patch had caused a bootstrap failure. The problem turned out to be an assembler bug ([1]). I've adjusted my patch to work around the problem. This is the only real way to do it given that, even if I fixed the assembler right away, there'll be broken assemblers knocking around for some time to come. The compiler now bootstraps correctly in a manual build. I've submitted it for testing on Michael's systems, so hopefully this patch will be ready to post back upstream soonish. Continued trying to figure out the neon shifts bootstrap failure. I ran a cross-compiler test suite run, but didn't witness any obvious problems. Launched a manual bootstrap to reproduce the problem (once the board because available after testing the immediates patch), so I should have something to work with next week. Attempted to merge lp:gcc/4.7 to lp:gcc-linaro/4.7, but got a bzr error. I asked for help on #bzr, and 'jelmer' is looking into it. Apparently the history didn't import in quite the same way as lp:gcc/trunk, or something. Helped Dmitry Antipov with a relocation (possible) bug. * Other Two days leave (Thursday and Friday). Booked flights and hotels to Hong Kong for Linaro Connect Q2.12 [1] http://sourceware.org/bugzilla/show_bug.cgi?id=13843 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 19/03/12 08:48, Konstantinos Margaritis wrote: On Sun, 18 Mar 2012 23:27:17 + Mans Rullgard 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 19 March 2012 21:48, Konstantinos Margaritis wrote: > On Sun, 18 Mar 2012 23:27:17 + > Mans Rullgard 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
Re: Plan for changing the binary toolchain to 4.7 and hardfloat
On 20 March 2012 01:42, Andrew Stubbs 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 ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
tcpanda auto builders going offline
The Validation lab is shifting to a new location this week so I've started a graceful shutdown of the tcpanda boards. Merge requests will continue to queue and run on x86 but will back up until the lab comes online at the end of this week. If the backlog gets too big then I'll re-enable an ursa board or two. Please work as normal but expect the builds results to take longer to come through. -- Michael ___ linaro-toolchain mailing list linaro-toolchain@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-toolchain
