On 08/13/2014 07:49 PM, Khem Raj wrote:
>
>
> On Wednesday, August 13, 2014, Peter A. Bigot <pab@pabigot.com 
> <mailto:pab@pabigot.com>> wrote:
>
>     On 08/13/2014 05:05 PM, Khem Raj wrote:
>
>         On Wed, Aug 13, 2014 at 2:36 PM, Peter A. Bigot
>         <pab@pabigot.com> wrote:
>
>             In any case, Khem can you run with this?  It'd be fixed a
>             lot better that
>             way....
>
>         We do not configure target gcc with right matching cpu defaults,
>         atomic instruction strex/ldrex are only added after armv6 but
>         defaults
>         for gcc if not specified is armv5t and hence it does not use
>         the right
>         set as expected by libstdc++ which has been cross compiled. so
>         while
>         you are at it and can reproduce it. Try to add
>
>         EXTRA_OECONF += '${@bb.utils.contains("TUNE_FEATURES", "armv7a", "
>         --with-cpu=armv7-a", "", d)}'
>
>         to gcc-target.inc and see if resulting gcc is any better
>
>
>     I had to make it:
>
>     EXTRA_OECONF += '${@bb.utils.contains("TUNE_FEATURES", "armv7a",
>     "--with-cpu=generic-armv7-a", "", d)}'
>
>
> Sorry a typo there you   need  --with-arch

OK, that works. So do we need to do the same thing for every 
TUNE_FEATURES element that ends up changing the value of -march= in 
TUNE_CCARGS which ends up getting passed into gcc-runtime?

If so would it be better to add a TUNE_ARCH setting to all the 
tune-foo.inc files and use that in both TUNE_CCARGS and the --with-arch= 
flag passed to gcc?  Just to avoid having this stuff hidden inside 
gcc-target.inc where it's pretty obscure.

>
> to get gcc to build but at runtime I then get:
>
>
>     beaglebone[16]$ g++ -std=c++11 -pthread test.cc && ./a.out
>     Assembler messages:
>     Error: unknown cpu `generic-armv7-a'
>     Error: unrecognized option -mcpu=generic-armv7-a
>
>     which indicates the flag's being passed to the assembler which
>     doesn't recognize it even though g++ is happy with it.  I suppose
>     we could hack binutils to substitute whatever spelling it wants to
>     see.
>
>     (Also tried --with-cpu=arm7, but that generates assembler errors
>     related to unsupported RM mode "bx lr").
>
>     The approach bothers me, though.  Instead of explicitly changing
>     gcc-target to match gcc-runtime, shouldn't it be a general rule
>     that gcc-runtime not apply OE-specific target flags that aren't
>     going to be used by direct invocations of the compiler outside of
>     the OE build environment?  That seems a little more robust, as the
>     default target flags may be changed upstream or by bbappends
>     within OE, and having to make them match in gcc-runtime as well
>     would be a headache.
>

Just to record one reason why this isn't trivial: although it's possible 
to strip ${TARGET_CC_ARCH} from ${CXX}, doing so removes 
-mfloat-abi=hard which makes gcc-runtime try to build a library that 
supports soft float, and the compiler didn't generate the necessary 
gnu/stubs-soft.h header for that.

>
>     And would we need similar overrides for other architectures?
>     There's something similar already in gcc-configure-common.inc for
>     mips64.
>
>     Peter
>