[OE-core] boost 1.56 compile fail
Peter A. Bigot
pab at pabigot.com
Sun Sep 28 09:55:40 UTC 2014
On 09/27/2014 08:48 PM, Yi Qingliang wrote:
>
> https://github.com/boostorg/atomic/commit/415db7054723291042e4ff1ffa8fdd5bc8b07163
>
> Please, see if it helps in your case.
> https://svn.boost.org/trac/boost/ticket/10446
This is probably a good patch to apply to boost 1.56 in OE, but it's too
large to qualify as "obvious". I use neither armv6 hosts nor Boost and
am not actively working OE at this time, so I can't verify that it works
on the target. Perhaps you, Dan, or somebody else will be willing to
create a recipe patch, validate it, and submit it here.
Peter
>
>
> On Mon, Sep 1, 2014 at 7:37 PM, Peter A. Bigot <pab at pabigot.com
> <mailto: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
>> <mailto: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
>> <mailto: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 <mailto: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
>> <mailto: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/ed31fcfc/attachment-0002.html>
More information about the Openembedded-core
mailing list