boost 1.56 compile fail

boost 1.56 compile fail

[Yi Qingliang]

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

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.

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?


Yi Qingliang

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

Re: boost 1.56 compile fail

[Yi Qingliang]

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

and use 'gcc_atomic' in platform.hpp just for 4.8.x 4.9.x,


#if ((defined(__GNUC__) && ((__GNUC__ * 100 + __GNUC_MINOR__) >= 407))

I don't know why low version gcc can do the lock free atomic operation, but
high version can't


On Fri, Aug 29, 2014 at 11:28 AM, Yi Qingliang <niqingliang2003@gmail.com>
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.
>
> 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?
>
>
> Yi Qingliang
>

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

Re: boost 1.56 compile fail

[Peter A. Bigot]

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

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.

Peter

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

Re: boost 1.56 compile fail

[Dan McGregor]

On 29 August 2014 05:48, Peter A. Bigot <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.


> Peter
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

Re: boost 1.56 compile fail

[Peter A. Bigot]

On 08/29/2014 03:36 PM, Dan McGregor wrote:
> On 29 August 2014 05:48, Peter A. Bigot <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?

Peter

Re: boost 1.56 compile fail

[Dan McGregor]

On 29 August 2014 14:58, Peter A. Bigot <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> 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
>

Re: boost 1.56 compile fail

[Peter A. Bigot]

On 08/29/2014 04:18 PM, Dan McGregor wrote:
> On 29 August 2014 14:58, Peter A. Bigot <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> 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

Re: boost 1.56 compile fail

[Peter A. Bigot]

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

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: 13050 bytes --]

Re: boost 1.56 compile fail

[Yi Qingliang]

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

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

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

Re: boost 1.56 compile fail

[Peter A. Bigot]

[-- 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 --]