Re: armv6k support in OE for raspberrypi and s3c6410

["Peter A. Bigot" <pab@pabigot.com>]

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