On 08/13/2014 07:49 PM, Khem Raj wrote:
On Wednesday, August 13, 2014, Peter A. Bigot <p...@pabigot.com
<mailto:p...@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
<p...@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
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
