On 29 August 2014 14:58, Peter A. Bigot <[email protected]> wrote: > 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? >
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. > Peter > -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
