[OE-core] boost 1.56 compile fail

[Dan McGregor]

On 29 August 2014 14:58, Peter A. Bigot <pab at pabigot.com> wrote:
> On 08/29/2014 03:36 PM, Dan McGregor wrote:
>>
>> 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.
>
>
> 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
>