https://github.com/boostorg/atomic/commit/415db7054723291042e4ff1ffa8fdd5bc8b07163
Please, see if it helps in your case. https://svn.boost.org/trac/boost/ticket/10446 On Mon, Sep 1, 2014 at 7:37 PM, Peter A. Bigot <[email protected]> wrote: > On 08/31/2014 09:31 PM, Yi Qingliang wrote: > > then what's your suggestion for now? > > > 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. > > If the s3c6410 does support ARMv6-K instructions, you can try making sure > it builds with -march=arvm6k. > > I don't know the conditions under which this becomes an OE-Core problem. > It's not a gcc problem. > > Peter > > > > > On Sat, Aug 30, 2014 at 9:14 AM, Peter A. Bigot <[email protected]> wrote: > >> On 08/29/2014 04:18 PM, Dan McGregor wrote: >> >>> 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. >>> >> >> 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] >> http://lists.openembedded.org/mailman/listinfo/openembedded-core >> > > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
