in multilibcase, PN has multilib prefix, so it is not
correct to use PN in SRC_URI and S. instead, we've
dedicately pruned multilib prefix in BPN, so BPN is
the right alternative for PN.
Signed-off-by: Yu Ke
---
.../farsight/farsight2_0.0.9.bb|2 +-
.../loudmouth/loudmou
in multilibcase, PN has multilib prefix, so it is not
correct to use PN in SRC_URI and S. instead, we've
dedicately pruned multilib prefix in BPN, so BPN is
the right alternative for PN.
The following changes since commit f94b781695cd8fa387daff16ecbf3987a0883018:
Bruce Ashfield (1):
pok
> -Original Message-
> From: openembedded-core-boun...@lists.openembedded.org
> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, July 29, 2011 11:38 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [RFC
On Wed, Jul 27, 2011 at 2:04 PM, Flanagan, Elizabeth
wrote:
> I would still pull it. It does give us a basis to work on and splits
> things out a bit.
> When I get back from the conference this week, I'll fix it so that
> it's a more reliable
> in returning results. My guess is that I'll have to
On 7/29/11 3:23 PM, Phil Blundell wrote:
> On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote:
>> Sorry I was gone much of yesterday and not able to comment. I'm going to
>> break
>> this down into the two problems that I see people having.
>>
>> 1) "interworking". I was recently told EABI requ
On Fri, 2011-07-29 at 13:08 -0500, Mark Hatle wrote:
> Sorry I was gone much of yesterday and not able to comment. I'm going to
> break
> this down into the two problems that I see people having.
>
> 1) "interworking". I was recently told EABI requires interworking to be
> enabled, and in OE-co
Sorry I was gone much of yesterday and not able to comment. I'm going to break
this down into the two problems that I see people having.
1) "interworking". I was recently told EABI requires interworking to be
enabled, and in OE-core we only support EABI. So we should always have the
interworkin
On Fri, Jul 29, 2011 at 07:04:33PM +0200, Martin Jansa wrote:
> Signed-off-by: Martin Jansa
> ---
> .../conf/machine/include/arm/feature-arm-thumb.inc |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
> b/meta/con
Signed-off-by: Martin Jansa
---
.../conf/machine/include/arm/feature-arm-thumb.inc |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
b/meta/conf/machine/include/arm/feature-arm-thumb.inc
index b580168..e7d392e 100644
--
This will decouple the compiling in thumb mode from having thumb
capable cores.
Signed-off-by: Khem Raj
---
.../conf/machine/include/arm/feature-arm-thumb.inc |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/arm/feature-arm-thumb.inc
b/meta/
On 07/29/2011 09:39 AM, Martin Jansa wrote:
On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
Currently when using thumb feature all recipes can not be compiled in
thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
set even when thumb was global choice. With this pa
On 07/29/2011 06:28 AM, Phil Blundell wrote:
There are quite a lot of different sub-threads going on at the moment
regarding the various breakages associated with the recent arm tuning
file patch. Here's a summary of what I think are all the current issues
and their status.
1. bogus PACKAGE_EXT
On Fri, Jul 29, 2011 at 07:59:31AM -0700, Khem Raj wrote:
> Currently when using thumb feature all recipes can not be compiled in
> thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
> set even when thumb was global choice. With this patch we remove thumb
> from tune features
On Fri, 2011-07-29 at 22:57 +0800, Lianhao Lu wrote:
> + "x86": ["ld-linux.so.2", "FLAG_ELF_LIBC5"],
That looks a bit weird to me. Are you sure that's right?
p.
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
Currently tune-xscale.inc has options wrt. setting of xscale/xscale-be tunes.
Fix that.
Signed-off-by: Dmitry Eremin-Solenikov
---
meta/conf/machine/include/tune-xscale.inc |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/meta/conf/machine/include/tune-xscale.inc
b/meta
On 07/28/2011 11:58 PM, Mei, Lei wrote:
>
>
>> -Original Message-
>> From: openembedded-core-boun...@lists.openembedded.org
>> [mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>> Tom Rini
>> Sent: Friday, July 29, 2011 9:44 AM
>> To: openembedded-core@lists.openembed
Op 29 jul. 2011 om 15:28 heeft Phil Blundell het volgende
geschreven:
> There are quite a lot of different sub-threads going on at the moment
> regarding the various breakages associated with the recent arm tuning
> file patch. Here's a summary of what I think are all the current issues
> and
Currently when using thumb feature all recipes can not be compiled in
thumb mode. Therefore we had ARM_INSTRUCTION_SET to force arm intruction
set even when thumb was global choice. With this patch we remove thumb
from tune features for these recipes. This will make sure that compiler
is not using
This is part of the BUG #1236 fixing. Current there seems no way to get the
dynamic loader(ld.so) names for all the ABIs configured in the multilib
configuration during runtime. So we put the ld.so names in the dictionary
"ld_info_all" in the file eglibc-ld.inc. This dictionary is indexed by the
Part fix of [BUGID #1236].
1. Collect all the values for RTLDLIST for the current multilib
configuration to modify the ldd scripts.
2. Collect all the values for KNOWN_INTERPRETER_NAMES for the current
multilib configuration.
Signed-off-by: Lianhao Lu
---
meta/recipes-core/eglibc/eglibc-ld.inc
1. Added variable MULTILIB_VARIANTS to store all the instance variants
for multilib extend.
2. Added function all_multilib_tune_values to collect the variable
values for all multilib instance.
Signed-off-by: Lianhao Lu
---
meta/classes/utils.bbclass | 35 +++
m
On Jul 28, 2011, at 10:07 PM, Saul Wold wrote:
> On 07/28/2011 06:57 PM, Kumar Gala wrote:
>>
>> On Jul 28, 2011, at 7:41 PM, Saul Wold wrote:
>>
>>> On 07/28/2011 05:07 PM, Kumar Gala wrote:
Its possible we get duplications if we explicity add TUNE_PKGARCH to
PACKAGE_ARCHS so instead
There are quite a lot of different sub-threads going on at the moment
regarding the various breakages associated with the recent arm tuning
file patch. Here's a summary of what I think are all the current issues
and their status.
1. bogus PACKAGE_EXTRA_ARCHS_tune-${DEFAULTTUNE} in bitbake.conf ca
Op 29 jul. 2011 om 09:25 heeft Phil Blundell het volgende
geschreven:
> On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
>> here I guess we have to say AVAILTUNES += "arm920t arm920"
>> where arm920 is arm mode and 920t is thumb mode. but anyway I would
>> prefer that thumb is optionally ad
On Fri, Jul 29, 2011 at 09:17:31AM +0200, Martin Jansa wrote:
> * PACKAGES were defined in eglibc.inc as well as eglibc-package.inc,
> definition
> from eglibc.inc was overriden from recipes including eglibc.inc only
> * 37ff0fea8f7180b1a9d91d24dfe1735730427497 changed RPROVIDES_eglibc-utils,
>
On Thu, 2011-07-28 at 22:59 -0700, Khem Raj wrote:
> here I guess we have to say AVAILTUNES += "arm920t arm920"
> where arm920 is arm mode and 920t is thumb mode. but anyway I would
> prefer that thumb is optionally added provided user asked for it
> through DISTRO/MACHINE features then we should
* PACKAGES were defined in eglibc.inc as well as eglibc-package.inc, definition
from eglibc.inc was overriden from recipes including eglibc.inc only
* 37ff0fea8f7180b1a9d91d24dfe1735730427497 changed RPROVIDES_eglibc-utils,
but ie FILES_ were still using eglibc-utils instead of ${PN}-utils, uni
On Thu, 2011-07-28 at 23:18 -0700, Khem Raj wrote:
> On 07/27/2011 07:44 AM, Phil Blundell wrote:
> cortex-m series supports only thumb2 intsruction set. I am not sure if
> thumb2 alone is a superset of thumb1 iow thumb1 programs could be
> executed on cortex-m series or not. Never had a cortex-m
On Thu, 2011-07-28 at 23:38 -0700, Khem Raj wrote:
> On 07/27/2011 08:25 AM, Phil Blundell wrote:
> > On Wed, 2011-07-27 at 09:58 -0500, Mark Hatle wrote:
> >> For the tune names.. armv5 means I want classic ARM instructions, while
> >> armv5t
> >> means I was thumb instructions.
> >>
> >> So arm
>-Original Message-
>From: openembedded-core-boun...@lists.openembedded.org
>[mailto:openembedded-core-boun...@lists.openembedded.org] On Behalf Of
>Tom Rini
>Sent: Friday, July 29, 2011 9:44 AM
>To: openembedded-core@lists.openembedded.org
>Subject: Re: [OE-core] [PATCH 1/1] python-nativ
30 matches
Mail list logo
