[OE-core] boost 1.56 compile fail
Peter A. Bigot
pab at pabigot.com
Mon Sep 1 11:37:01 UTC 2014
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/20140901/52e2fa53/attachment-0002.html>
More information about the Openembedded-core
mailing list