<br><br>On Wednesday, August 13, 2014, Peter A. Bigot <<a href="mailto:pab@pabigot.com">pab@pabigot.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 08/13/2014 05:05 PM, Khem Raj wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Aug 13, 2014 at 2:36 PM, Peter A. Bigot <<a>pab@pabigot.com</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
In any case, Khem can you run with this? It'd be fixed a lot better that<br>
way....<br>
</blockquote>
We do not configure target gcc with right matching cpu defaults,<br>
atomic instruction strex/ldrex are only added after armv6 but defaults<br>
for gcc if not specified is armv5t and hence it does not use the right<br>
set as expected by libstdc++ which has been cross compiled. so while<br>
you are at it and can reproduce it. Try to add<br>
<br>
EXTRA_OECONF += '${@bb.utils.contains("TUNE_<u></u>FEATURES", "armv7a", "<br>
--with-cpu=armv7-a", "", d)}'<br>
<br>
to gcc-target.inc and see if resulting gcc is any better<br>
</blockquote>
<br>
I had to make it:<br>
<br>
EXTRA_OECONF += '${@bb.utils.contains("TUNE_<u></u>FEATURES", "armv7a", "--with-cpu=generic-armv7-a", "", d)}'<br>
<br></blockquote><div><br></div><div>Sorry a typo there you need --with-arch</div><div><br></div><div>to get gcc to build but at runtime I then get:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
beaglebone[16]$ g++ -std=c++11 -pthread test.cc && ./a.out<br>
Assembler messages:<br>
Error: unknown cpu `generic-armv7-a'<br>
Error: unrecognized option -mcpu=generic-armv7-a<br>
<br>
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.<br>
<br>
(Also tried --with-cpu=arm7, but that generates assembler errors related to unsupported RM mode "bx lr").<br>
<br>
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.<br>
<br>
And would we need similar overrides for other architectures? There's something similar already in gcc-configure-common.inc for mips64.<br>
<br>
Peter<br>
</blockquote>