On 08/30/2014 02:49 AM, Richard Purdie wrote:
On target is harder however the on target gcc is compiled to a specific PACKAGE_ARCH so we should be able to put specific tuning into that gcc. It does sound like the changes to gcc-configure-common.inc were not the way to resolve this though, I'd misunderstood what the patches were doing.
Sorry; I misunderstood what -mtune was meant to do and made it sound worse than it is. -mtune must be used in conjunction with -march and does not provide a default architecture as I had expected. It's -mcpu that defaults -march.
--with-arch=foo in gcc's configuration switches is doing exactly what it should and I believe it's the best approach with minimal impact on how OE toolchains have historically been built and invoked. I have no concerns about this resolution.
(If others are less trusting, I have patches to revert the --with-arch change and remove the TARGET_CC_ARCH stuff from gcc-runtime, which is an alternative approach that also meets my requirement. But that has a much wider impact than what we're doing now and I don't think it's a good approach.)
On full investigation, the Boost issue is completely unrelated. Boost 1.56 simply will not work with any platform that explicitly uses -march=armv6. That needs to be fixed in Boost; reverting gcc won't help.
Alternatively meta-raspberrypi could set -march=armv6k and deal with the ramifications of doing that (viz making PACKAGE_ARCH reflect the difference from armv6). There's nothing at all wrong about it being armv6 as it is now: it just wouldn't be the best choice for atomic operations if armv6k were a supported option.
Peter -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
