On Sat, Aug 30, 2014 at 9:14 AM, Peter A. Bigot <[email protected]
<mailto:[email protected]>> wrote:
On 08/29/2014 04:18 PM, Dan McGregor wrote:
On 29 August 2014 14:58, Peter A. Bigot <[email protected]
<mailto:[email protected]>> wrote:
On 08/29/2014 03:36 PM, Dan McGregor wrote:
On 29 August 2014 05:48, Peter A. Bigot
<[email protected] <mailto:[email protected]>> wrote:
On 08/29/2014 06:28 AM, Yi Qingliang wrote:
hardware: samsung s3c6410
after updated to latest poky, the boost
compile fail!
error info:
libs/atomic/src/lockpool.cpp:127:5: error:
'thread_fence' is not a member
of
'boost::atomics::detail'
libs/atomic/src/lockpool.cpp:138:5: error:
'signal_fence' is not a member
of
'boost::atomics::detail'
after dig into it, I found that:
the marco 'BOOST_ATOMIC_FLAG_LOCK_FREE' is 0,
so it don't include
'operations_lockfree.hpp' which has
'thread_fence' and 'signal_fence',
but
pthread.h at line 21.
in file 'caps_gcc_atomic.hpp',
'BOOST_ATOMIC_FLAG_LOCK_FREE' is set to
'0',
the author think if
'__GCC_ATOMIC_BOOL_LOCK_FREE' is 1, the
atomic serial
function gcc provided is not lock free.
This is the sort of GCC internal header
indicator that would have changed
value as a result of:
http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=0ba6ab39f187ecd4261f08e768f365f461384a3a
at the end of 'caps_gcc_atomic.hpp', it defined
'BOOST_ATOMIC_THREAD_FENCE'
as 2.
so the conflict is: BOOST_ATOMIC_THREAD_FENCE and
BOOST_ATOMIC_FLAG_LOCK_FREE
I don't know it is the new poky problem, or
the boost problem, any idea?
My guess is that Boost is making assumptions
about what the internal GCC
predefined symbols mean that aren't entirely
accurate. There are several
flags that are used in the libstdc++ headers
to indicate whether the
compiler is using lock-free instructions.
Boost-1.56 builds without error for my
beaglebone target with poky at:
* 669c07d (HEAD, origin/master, origin/HEAD,
master/upstream, master/dev)
[Wed Aug 27 14:24:52 2014 +0100] bitbake:
build/data: Write out more
complete python run files
so it may have something to do with your
target machine.
It absolutely does. I found that armv6 breaks,
but armv6zk and newer work.
Interesting. There are no armv6zk tune features I
can see in poky, though
google suggests it applies to the Raspberry Pi.
The problem then must be with the first override in this:
# ARMv6+ adds atomic instructions that affect the ABI
in libraries built
# with TUNE_CCARGS in gcc-runtime. Make the compiler
default to a
# compatible architecture. armv6 and armv7a cover
the minimum tune
# features used in OE.
EXTRA_OECONF_append_armv6 = " --with-arch=armv6"
EXTRA_OECONF_append_armv7a = " --with-arch=armv7-a"
ARMv6 has LDREX/STREX, but ARMv6K adds
{LD,ST}REX{B,H,D}. The same problem
addressed above is likely to happen if the libraries
are built with armv6k
but the compiler doesn't default to it.
There are no armv6k tune parameters I can locate in
poky. What layers have
the tune configurations that are causing problems?
For me meta-raspberrypi failed to build. Its tuning is
-march=armv6
-mtune=arm1176zjf-s by default. I forced it to -march=armv6zk
-mtune=arm1176jzf-s, and that worked.
tl;dr: for now, this can be claimed to be a boost problem,
but it may rapidly become an OE problem.
OK, so there's several issues here.
Extracting the predefined symbols from gcc 4.9.1 with:
arm-poky-linux-gnueabi-g++ -march=armv6 -dM -E -xc++ /dev/null
and similarly with -march=armv6k shows that the values of
these atomic-related predefines are different (- = arvm6, + =
armv6k):
-#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
-#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
+#define __GCC_ATOMIC_BOOL_LOCK_FREE 2
+#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 2
-#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
+#define __GCC_ATOMIC_CHAR_LOCK_FREE 2
-#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
+#define __GCC_ATOMIC_LLONG_LOCK_FREE 2
-#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
+#define __GCC_ATOMIC_SHORT_LOCK_FREE 2
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_1 1
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_2 1
+#define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_8 1
(armv6zk is the same as armv6k for atomic-related capabilities.)
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.
That's a boost problem.
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.)
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).
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.
Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
<mailto:[email protected]>
http://lists.openembedded.org/mailman/listinfo/openembedded-core
