[OE-core] boost 1.56 compile fail

Sun Sep 28 01:48:29 UTC 2014

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 <pab at pabigot.com> 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 <pab at pabigot.com> wrote:
>
>>  On 08/29/2014 04:18 PM, Dan McGregor wrote:
>>
>>> 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.
>>>
>>
>>  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
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openembedded.org/pipermail/openembedded-core/attachments/20140928/c4c4b753/attachment-0002.html>