| Summary: | qt build failure with Sourcery CodeBench ARM 2010.09 | ||
|---|---|---|---|
| Product: | buildroot | Reporter: | Luca Ceresoli <luca.ceresoli> |
| Component: | Other | Assignee: | unassigned |
| Status: | RESOLVED WONTFIX | ||
| Severity: | minor | CC: | buildroot, luca.ceresoli |
| Priority: | P5 | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Host: | Target: | ||
| Build: | |||
| Attachments: | Defconfig to reproduce the problem | ||
|
Description
Luca Ceresoli
2012-07-26 20:34:42 UTC
This is a gcc 4.5 bug, as discussed in great detail at https://bugs.launchpad.net/gcc-linaro/+bug/675347 and it affects Sourcery 2010.09 too. The bug has been fixed in later gcc (and thus Sourcery) releases, but there is a workaround in comment 23 in the launchpad bug page above. Just adding -fno-strict-volatile-bitfields to the compilation options makes Qt build and run. Note that this flag needs to be added to Qt *and* all programs using it, since the line triggering the error is in an include file. Should I submit a patch so that BR2_TARGET_OPTIMIZATION defaults to a value with this flag when Sourcery 2010.09 is in use? Or just document it in BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201009? PS: Thomas, do you think it could be wise to add all supported toolchains (including this one) to your build server? (In reply to comment #2) > PS: Thomas, do you think it could be wise to add all supported toolchains > (including this one) to your build server? Yes. I actually already have a bunch of CodeSourcery toolchains, but not 2010.09. I.e, I have: ARM 2010q1, ARM 2011.03 default multilib, ARM 2011.03 ARMv4 multilib, ARM 2011.09 default multilib, ARM 2011.09 thumb2 multilib. I also have x86, MIPS and PowerPC CodeSourcery toolchains. But yes, I could plan on adding *all* toolchains that we support, just to give more build coverage. Generally speaking, the automated test builds are really only in v1 at the moment, I have a lot of ideas to improve the build coverage, and to provide a more useful Web interface for them. (In reply to comment #1) > Should I submit a patch so that BR2_TARGET_OPTIMIZATION defaults to a value > with this flag when Sourcery 2010.09 is in use? Or just document it in > BR2_TOOLCHAIN_EXTERNAL_CODESOURCERY_ARM201009? Though I fully admit with the goal of ensuring that each and every configuration that an user can come up with should build, I am not sure adding this option globally to the build when this toolchain is used is a good idea. I think in this specific case, I would prefer that we add a "Known issues" chapter in the documentation, in which we list known problems and their solutions. We've removed the support for ARM CS 2010.09 since a long time, so this bug cannot occur anymore with the existing toolchain profiles. |