[OE-core] boost 1.56 compile fail

[Peter A. Bigot]

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.

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140829/fcbbb1e8/attachment-0002.html>