<div dir="ltr"><br> <a href="https://github.com/boostorg/atomic/commit/415db7054723291042e4ff1ffa8fdd5bc8b07163" target="_blank">https://github.com/boostorg/atomic/commit/415db7054723291042e4ff1ffa8fdd5bc8b07163</a><br><br> Please, see if it helps in your case.<div class=""><div id=":bb" class="" tabindex="0"><a href="https://svn.boost.org/trac/boost/ticket/10446" target="_blank">https://svn.boost.org/trac/boost/ticket/10446</a><br></div></div><div class=""><div class="adm" style="font-family:arial,sans-serif;font-size:13px"></div></div><div><span class=""><font color="#888888"><br></font></span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Sep 1, 2014 at 7:37 PM, Peter A. Bigot <span dir="ltr"><<a href="mailto:pab@pabigot.com" target="_blank">pab@pabigot.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><span class="">
<div>On 08/31/2014 09:31 PM, Yi Qingliang
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">then what's your suggestion for now?</div>
</blockquote>
<br></span>
If the s3c6410 is ARMv6 and does not support ARMv6-K instructions,
then boost 1.56 does not work for your platform. Try downgrading to
1.55, or asking the Boost folks for a patch to update
boost/atomic/detail/caps_gcc_atomic.hpp so that it supports that
architecture, which lacks the byte, half-word, and double-word
atomic ldrex/strex instruction variants.<br>
<br>
If the s3c6410 does support ARMv6-K instructions, you can try making
sure it builds with -march=arvm6k.<br>
<br>
I don't know the conditions under which this becomes an OE-Core
problem. It's not a gcc problem.<span class="HOEnZb"><font color="#888888"><br>
<br>
Peter</font></span><div><div class="h5"><br>
<br>
<blockquote type="cite">
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Sat, Aug 30, 2014 at 9:14 AM, Peter
A. Bigot <span dir="ltr"><<a href="mailto:pab@pabigot.com" target="_blank">pab@pabigot.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div>On 08/29/2014 04:18 PM, Dan McGregor
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 29 August 2014 14:58, Peter A. Bigot <<a href="mailto:pab@pabigot.com" target="_blank">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/29/2014 03:36 PM, Dan McGregor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 29 August 2014 05:48, Peter A. Bigot <<a href="mailto:pab@pabigot.com" target="_blank">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/29/2014 06:28 AM, Yi Qingliang wrote:<br>
<br>
hardware: samsung s3c6410<br>
<br>
after updated to latest poky, the boost compile
fail!<br>
<br>
error info:<br>
libs/atomic/src/lockpool.cpp:127:5: error:
'thread_fence' is not a member<br>
of<br>
'boost::atomics::detail'<br>
libs/atomic/src/lockpool.cpp:138:5: error:
'signal_fence' is not a member<br>
of<br>
'boost::atomics::detail'<br>
<br>
<br>
after dig into it, I found that:<br>
the marco 'BOOST_ATOMIC_FLAG_LOCK_FREE' is 0, so
it don't include<br>
'operations_lockfree.hpp' which has
'thread_fence' and 'signal_fence',<br>
but<br>
pthread.h at line 21.<br>
<br>
in file 'caps_gcc_atomic.hpp',
'BOOST_ATOMIC_FLAG_LOCK_FREE' is set to<br>
'0',<br>
the author think if
'__GCC_ATOMIC_BOOL_LOCK_FREE' is 1, the atomic
serial<br>
function gcc provided is not lock free.<br>
<br>
<br>
This is the sort of GCC internal header
indicator that would have changed<br>
value as a result of:<br>
<br>
<br>
<a href="http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=0ba6ab39f187ecd4261f08e768f365f461384a3a" target="_blank">http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=0ba6ab39f187ecd4261f08e768f365f461384a3a</a><br>
<br>
<br>
<br>
at the end of 'caps_gcc_atomic.hpp', it defined<br>
'BOOST_ATOMIC_THREAD_FENCE'<br>
as 2.<br>
<br>
so the conflict is: BOOST_ATOMIC_THREAD_FENCE
and<br>
BOOST_ATOMIC_FLAG_LOCK_FREE<br>
<br>
I don't know it is the new poky problem, or the
boost problem, any idea?<br>
<br>
<br>
My guess is that Boost is making assumptions
about what the internal GCC<br>
predefined symbols mean that aren't entirely
accurate. There are several<br>
flags that are used in the libstdc++ headers to
indicate whether the<br>
compiler is using lock-free instructions.<br>
<br>
Boost-1.56 builds without error for my
beaglebone target with poky at:<br>
<br>
* 669c07d (HEAD, origin/master, origin/HEAD,
master/upstream, master/dev)<br>
[Wed Aug 27 14:24:52 2014 +0100] bitbake:
build/data: Write out more<br>
complete python run files<br>
<br>
so it may have something to do with your target
machine.<br>
</blockquote>
It absolutely does. I found that armv6 breaks, but
armv6zk and newer work.<br>
</blockquote>
<br>
Interesting. There are no armv6zk tune features I
can see in poky, though<br>
google suggests it applies to the Raspberry Pi.<br>
<br>
The problem then must be with the first override in
this:<br>
<br>
# ARMv6+ adds atomic instructions that affect the
ABI in libraries built<br>
# with TUNE_CCARGS in gcc-runtime. Make the
compiler default to a<br>
# compatible architecture. armv6 and armv7a cover
the minimum tune<br>
# features used in OE.<br>
EXTRA_OECONF_append_armv6 = " --with-arch=armv6"<br>
EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a"<br>
<br>
ARMv6 has LDREX/STREX, but ARMv6K adds
{LD,ST}REX{B,H,D}. The same problem<br>
addressed above is likely to happen if the libraries
are built with armv6k<br>
but the compiler doesn't default to it.<br>
<br>
There are no armv6k tune parameters I can locate in
poky. What layers have<br>
the tune configurations that are causing problems?<br>
<br>
</blockquote>
For me meta-raspberrypi failed to build. Its tuning is
-march=armv6<br>
-mtune=arm1176zjf-s by default. I forced it to
-march=armv6zk<br>
-mtune=arm1176jzf-s, and that worked.<br>
</blockquote>
<br>
</div>
</div>
tl;dr: for now, this can be claimed to be a boost problem,
but it may rapidly become an OE problem.<br>
<br>
OK, so there's several issues here.<br>
<br>
Extracting the predefined symbols from gcc 4.9.1 with:<br>
<br>
arm-poky-linux-gnueabi-g++ -march=armv6 -dM -E -xc++
/dev/null<br>
<br>
and similarly with -march=armv6k shows that the values of
these atomic-related predefines are different (- = arvm6, +
= armv6k):<br>
<br>
-#define __GCC_ATOMIC_BOOL_LOCK_FREE 1<br>
-#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1<br>
+#define __GCC_ATOMIC_BOOL_LOCK_FREE 2<br>
+#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2<br>
-#define __GCC_ATOMIC_CHAR_LOCK_FREE 1<br>
+#define __GCC_ATOMIC_CHAR_LOCK_FREE 2<br>
-#define __GCC_ATOMIC_LLONG_LOCK_FREE 1<br>
+#define __GCC_ATOMIC_LLONG_LOCK_FREE 2<br>
-#define __GCC_ATOMIC_SHORT_LOCK_FREE 1<br>
+#define __GCC_ATOMIC_SHORT_LOCK_FREE 2<br>
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1<br>
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1<br>
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1<br>
<br>
(armv6zk is the same as armv6k for atomic-related
capabilities.)<br>
<br>
boost/atomic/detail/caps_gcc_atomic.hpp apparently does not
provide an implementation of thread_fence or signal_fence
for the armv6 configuration, only for the armv6k and later
ones.<br>
<br>
That's a boost problem.<br>
<br>
The fact that -mtune=arm1176jzf-s apparently doesn't enable
the armv6k features even though gcc's source code implies it
should is an anomaly. (Check this by substituting
-mtune=arm1176jzf-s for -march=armv6 and verifying that the
predefined symbols are the same for both configurations.)<br>
<br>
If that anomaly is ever resolved, or if meta-raspberrypi
chooses to switch to -march=armv6zk, then
gcc-configure-common.inc almost certainly need to recognize
armv6k as an override distinct from armv6: mutex-related
code built for armv6k via gcc-runtime will result in a
different ABI from mutex-related code built for armv6 (what
gcc will produce for builds that do not use OE's tuning
parameters).<br>
<br>
If the solution to the boost problem is to change
meta-raspberrypi to use -march=armv6k then
gcc-configure-common.inc will need to be updated as well.
Probably OE should recognize it as a distinct ARM
architecture too.
<div>
<div><br>
<br>
Peter<br>
-- <br>
_______________________________________________<br>
Openembedded-core mailing list<br>
<a href="mailto:Openembedded-core@lists.openembedded.org" target="_blank">Openembedded-core@lists.openembedded.org</a><br>
<a href="http://lists.openembedded.org/mailman/listinfo/openembedded-core" target="_blank">http://lists.openembedded.org/mailman/listinfo/openembedded-core</a><br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div>