On 08/29/2014 03:36 PM, Dan McGregor wrote:
On 29 August 2014 05:48, Peter A. Bigot <[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?
Peter
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
