[OE-core] boost 1.56 compile fail

Dan McGregor danismostlikely at gmail.com
Fri Aug 29 20:36:49 UTC 2014


On 29 August 2014 05:48, Peter A. Bigot <pab at pabigot.com> 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.


> Peter
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core at lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



More information about the Openembedded-core mailing list