[OE-core] armv6k support in OE for raspberrypi and s3c6410
Peter A. Bigot
pab at pabigot.com
Sat Aug 30 16:54:20 UTC 2014
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
More information about the Openembedded-core
mailing list