Re: boost 1.56 compile fail

["Peter A. Bigot" <pab@pabigot.com>]

[-- Attachment #1: Type: text/plain, Size: 10010 bytes --]

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@pabigot.com 
> <mailto:pab@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@pabigot.com
>>     <mailto:pab@pabigot.com>> wrote:
>>
>>         On 08/29/2014 04:18 PM, Dan McGregor wrote:
>>
>>             On 29 August 2014 14:58, Peter A. Bigot <pab@pabigot.com
>>             <mailto:pab@pabigot.com>> wrote:
>>
>>                 On 08/29/2014 03:36 PM, Dan McGregor wrote:
>>
>>                     On 29 August 2014 05:48, Peter A. Bigot
>>                     <pab@pabigot.com <mailto:pab@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@lists.openembedded.org
>>         <mailto:Openembedded-core@lists.openembedded.org>
>>         http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>
>
>
>


[-- Attachment #2: Type: text/html, Size: 20102 bytes --]