[PATCH 00/10] Commits to enable x32 infrastructure

[PATCH 00/10] Commits to enable x32 infrastructure

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

Here are commits to enable infrastructure for use of x32 layer.

The kernel fixes from Bruce are for getting linux-korg recipe to work.

The following changes since commit 5561aaad28ed6db6d962f88db32814043044731f:

  eglibc: Fix patch merge breakage (2011-08-04 15:41:19 +0100)

are available in the git repository at:
  git://git.pokylinux.org/poky-contrib nitin/x32.rebased
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/x32.rebased

Bruce Ashfield (3):
  kern-tools: extend arbitrary repository support
  linux-yocto: process the existing branch for configuration
  linux-yocto: pass KMACHINE to updateme, not MACHINE

Nitin A Kamble (7):
  glibc: bring back the needed support for glibc recipes
  toolchain-scripts & other classes: add TARGET_LD_ARCH &
    TARGET_AS_ARCH vars
  kernel,module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars
  siteinfo.bbclass: add entries for new x86_64 ABI targets
  insane.bbclass: add entries for linux-gnu<ABI>
  x86 tune inc files: add x32 abi tune parameters
  local.conf.sample: make BBMASK assignment weak

 meta-yocto/conf/local.conf.sample                  |    2 +-
 meta/classes/allarch.bbclass                       |    2 +
 meta/classes/cross-canadian.bbclass                |    2 +
 meta/classes/cross.bbclass                         |    2 +
 meta/classes/crosssdk.bbclass                      |    2 +
 meta/classes/insane.bbclass                        |    9 +++++
 meta/classes/kernel-yocto.bbclass                  |   11 +-----
 meta/classes/kernel.bbclass                        |    2 +-
 meta/classes/module-base.bbclass                   |    4 +-
 meta/classes/native.bbclass                        |   10 ++++--
 meta/classes/nativesdk.bbclass                     |    4 ++
 meta/classes/siteinfo.bbclass                      |   14 ++++++++-
 meta/classes/toolchain-scripts.bbclass             |    9 +++--
 meta/conf/bitbake.conf                             |   23 ++++++++++----
 meta/conf/distro/include/tclibc-glibc.inc          |   32 ++++++++++++++++++++
 meta/conf/distro/include/tcmode-default.inc        |    5 +++
 meta/conf/machine/include/ia32/arch-ia32.inc       |   23 ++++++++++++--
 meta/conf/machine/include/tune-core2.inc           |    4 ++
 meta/conf/machine/include/tune-x86_64.inc          |    2 +-
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 20 files changed, 132 insertions(+), 32 deletions(-)
 create mode 100644 meta/conf/distro/include/tclibc-glibc.inc

-- 
1.7.6

[PATCH 01/10] kern-tools: extend arbitrary repository support

[nitin.a.kamble]

From: Bruce Ashfield <bruce.ashfield@windriver.com>

Updating the kern-tools SRCREV to pickup better support for
non-yocto repository support.

  59859ca createme: use branch name when creating meta data
  91b4275 configme: determine meta branch based on directories, not branch naming
  f5a915c kgit-meta: make branch creation and renaming more robust

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 .../kern-tools/kern-tools-native_git.bb            |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
index 1fbb1f7..7ede52a 100644
--- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
+++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
 
 DEPENDS = "git-native guilt-native"
 
-SRCREV = "f5a915c277a37ba5949b4c0778356189e7dd9ec0"
+SRCREV = "cdcb97cfea5f98003b2e0fb1a77b6d0d016a69e7"
 PR = r10
 PV = "0.1+git${SRCPV}"
 
-- 
1.7.6

Re: [PATCH 01/10] kern-tools: extend arbitrary repository support

[Bruce Ashfield]

On Thu, Aug 4, 2011 at 11:01 AM,  <nitin.a.kamble@intel.com> wrote:
> From: Bruce Ashfield <bruce.ashfield@windriver.com>
>
> Updating the kern-tools SRCREV to pickup better support for
> non-yocto repository support.
>
>  59859ca createme: use branch name when creating meta data
>  91b4275 configme: determine meta branch based on directories, not branch naming
>  f5a915c kgit-meta: make branch creation and renaming more robust

This one still needs a bit more testing. I'll be sending a pull request when
I'm happy with it on Friday. So let's wait a just a bit longer for this.

Bruce

>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  .../kern-tools/kern-tools-native_git.bb            |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index 1fbb1f7..7ede52a 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8
>
>  DEPENDS = "git-native guilt-native"
>
> -SRCREV = "f5a915c277a37ba5949b4c0778356189e7dd9ec0"
> +SRCREV = "cdcb97cfea5f98003b2e0fb1a77b6d0d016a69e7"
>  PR = r10
>  PV = "0.1+git${SRCPV}"
>
> --
> 1.7.6
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

[PATCH 02/10] linux-yocto: process the existing branch for configuration

[nitin.a.kamble]

From: Bruce Ashfield <bruce.ashfield@windriver.com>

When building an external tree or bootstrapping a BSP the
external branch may not have been checked out. The tools now ensure
that the tree is ready for configuration, so we no longer need to
force the checkout of the external branch.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel-yocto.bbclass |    9 +--------
 1 files changed, 1 insertions(+), 8 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index a374df1..8df5f31 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -87,14 +87,7 @@ do_kernel_configme() {
 	echo "[INFO] doing kernel configme"
 
 	kbranch=${KBRANCH}
-	if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
-           # switch from a generic to a specific branch
-           kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
-           cd ${S}
-           git checkout ${kbranch}
-	else
-	   cd ${S}
-	fi
+	cd ${S}
 
 	configme --reconfig --output ${B} ${kbranch} ${MACHINE}
 	if [ $? -ne 0 ]; then
-- 
1.7.6

Re: [PATCH 02/10] linux-yocto: process the existing branch for configuration

[Bruce Ashfield]

On Thu, Aug 4, 2011 at 11:01 AM,  <nitin.a.kamble@intel.com> wrote:
> From: Bruce Ashfield <bruce.ashfield@windriver.com>
>
> When building an external tree or bootstrapping a BSP the
> external branch may not have been checked out. The tools now ensure
> that the tree is ready for configuration, so we no longer need to
> force the checkout of the external branch.

This broke one use case, which may be fine, but I'll include this in my
pull request once all testing is complete.

Bruce

>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel-yocto.bbclass |    9 +--------
>  1 files changed, 1 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
> index a374df1..8df5f31 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -87,14 +87,7 @@ do_kernel_configme() {
>        echo "[INFO] doing kernel configme"
>
>        kbranch=${KBRANCH}
> -       if [ -n "${YOCTO_KERNEL_EXTERNAL_BRANCH}" ]; then
> -           # switch from a generic to a specific branch
> -           kbranch=${YOCTO_KERNEL_EXTERNAL_BRANCH}
> -           cd ${S}
> -           git checkout ${kbranch}
> -       else
> -          cd ${S}
> -       fi
> +       cd ${S}
>
>        configme --reconfig --output ${B} ${kbranch} ${MACHINE}
>        if [ $? -ne 0 ]; then
> --
> 1.7.6
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

[PATCH 03/10] linux-yocto: pass KMACHINE to updateme, not MACHINE

[nitin.a.kamble]

From: Bruce Ashfield <bruce.ashfield@windriver.com>

To support the mapping of any oe/yocto MACHINE to a kernel
branch that may not share that naming structure we have
KMACHINE and KBRANCH. To allow the mapping to work, we
actually have to pass KMACHINE into updateme and not MACHINE.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel-yocto.bbclass |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
index 8df5f31..e242165 100644
--- a/meta/classes/kernel-yocto.bbclass
+++ b/meta/classes/kernel-yocto.bbclass
@@ -28,7 +28,7 @@ do_patch() {
 			addon_features="$addon_features --feature $feat"
 		done
 	fi
-	updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE} ${WORKDIR}
+	updateme --branch ${kbranch} ${addon_features} ${ARCH} ${KMACHINE} ${WORKDIR}
 	if [ $? -ne 0 ]; then
 		echo "ERROR. Could not update ${kbranch}"
 		exit 1
-- 
1.7.6

Re: [PATCH 03/10] linux-yocto: pass KMACHINE to updateme, not MACHINE

[Bruce Ashfield]

On Thu, Aug 4, 2011 at 11:01 AM,  <nitin.a.kamble@intel.com> wrote:
> From: Bruce Ashfield <bruce.ashfield@windriver.com>
>
> To support the mapping of any oe/yocto MACHINE to a kernel
> branch that may not share that naming structure we have
> KMACHINE and KBRANCH. To allow the mapping to work, we
> actually have to pass KMACHINE into updateme and not MACHINE.

This has also been rebased. I'll include this in my pull request tomorrow. I'm
still doing regression testing on this change.

Bruce

>
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel-yocto.bbclass |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/kernel-yocto.bbclass b/meta/classes/kernel-yocto.bbclass
> index 8df5f31..e242165 100644
> --- a/meta/classes/kernel-yocto.bbclass
> +++ b/meta/classes/kernel-yocto.bbclass
> @@ -28,7 +28,7 @@ do_patch() {
>                        addon_features="$addon_features --feature $feat"
>                done
>        fi
> -       updateme --branch ${kbranch} ${addon_features} ${ARCH} ${MACHINE} ${WORKDIR}
> +       updateme --branch ${kbranch} ${addon_features} ${ARCH} ${KMACHINE} ${WORKDIR}
>        if [ $? -ne 0 ]; then
>                echo "ERROR. Could not update ${kbranch}"
>                exit 1
> --
> 1.7.6
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

[PATCH 04/10] glibc: bring back the needed support for glibc recipes

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/conf/distro/include/tclibc-glibc.inc   |   32 +++++++++++++++++++++++++++
 meta/conf/distro/include/tcmode-default.inc |    5 ++++
 2 files changed, 37 insertions(+), 0 deletions(-)
 create mode 100644 meta/conf/distro/include/tclibc-glibc.inc

diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
new file mode 100644
index 0000000..823195c
--- /dev/null
+++ b/meta/conf/distro/include/tclibc-glibc.inc
@@ -0,0 +1,32 @@
+#
+# glibc specific configuration
+#
+
+LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or '') != '']}"
+
+# Add glibc to the overrides.
+OVERRIDES =. "libc-glibc:"
+
+PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
+PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= "glibc-nativesdk"
+PREFERRED_PROVIDER_virtual/libintl ?= "glibc"
+PREFERRED_PROVIDER_virtual/libc ?= "glibc"
+PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "glibc-nativesdk"
+PREFERRED_PROVIDER_virtual/libc-locale ?= "glibc-locale"
+
+CXXFLAGS += "-fvisibility-inlines-hidden"
+
+LIBC_DEPENDENCIES = "\
+    libsegfault \
+    glibc \
+    glibc-dbg \
+    glibc-dev \
+    glibc-utils \
+    glibc-thread-db \
+    glibc-localedata-i18n \
+    glibc-gconv-ibm850 \
+    glibc-gconv-cp1252 \
+    glibc-gconv-iso8859-1 \
+    glibc-gconv-iso8859-15 \
+    locale-base-en-gb \
+    "
diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
index 0d0af38..5f66c9e 100644
--- a/meta/conf/distro/include/tcmode-default.inc
+++ b/meta/conf/distro/include/tcmode-default.inc
@@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?= "${BINUVERSION}"
 PREFERRED_VERSION_binutils-cross-canadian ?= "${BINUVERSION}"
 PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}"
 PREFERRED_VERSION_linux-libc-headers-nativesdk ?= "${LINUXLIBCVERSION}"
+PREFERRED_VERSION_glibc ?= "${GLIBCVERSION}"
+PREFERRED_VERSION_glibc-locale ?= "${GLIBCVERSION}"
+PREFERRED_VERSION_glibc-nativesdk ?= "${GLIBCVERSION}"
+PREFERRED_VERSION_glibc-initial ?= "${GLIBCVERSION}"
+PREFERRED_VERSION_glibc-initial-nativesdk ?= "${GLIBCVERSION}"
 PREFERRED_VERSION_eglibc                   ?= "${EGLIBCVERSION}"
 PREFERRED_VERSION_eglibc-locale            ?= "${EGLIBCVERSION}"
 PREFERRED_VERSION_eglibc-nativesdk         ?= "${EGLIBCVERSION}"
-- 
1.7.6

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Phil Blundell]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>

This commit message is very terse.  Why is this change necessary?

p.

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:51 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> This commit message is very terse.  Why is this change necessary?

Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree.
Thanks,
Nitin

> 
> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Phil Blundell]

On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Phil Blundell
> > Sent: Thursday, August 04, 2011 2:51 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> > support for glibc recipes
> > 
> > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > 
> > This commit message is very terse.  Why is this change necessary?
> 
> Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree.

Can't the tclibc-glibc file go in meta-x32 as well, then?

p.

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 3:10 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
> >
> > > -----Original Message-----
> > > From: openembedded-core-bounces@lists.openembedded.org
> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:51 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> > > support for glibc recipes
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > >
> > > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> > > This commit message is very terse.  Why is this change necessary?
> >
> > Because meta-x32 layer has glibc, which needs these support files. I
> will update the commit message in the tree.
> 
> Can't the tclibc-glibc file go in meta-x32 as well, then?
> 
It can go in the meta-x32 layer, but I think better place for this support file is in the meta layer. It would help avoid duplication of the code in multiple layers.

> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Tom Rini]

On Thu, Aug 4, 2011 at 3:47 PM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Phil Blundell
>> Sent: Thursday, August 04, 2011 3:10 PM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>> support for glibc recipes
>>
>> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
>> >
>> > > -----Original Message-----
>> > > From: openembedded-core-bounces@lists.openembedded.org
>> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>> Of
>> > > Phil Blundell
>> > > Sent: Thursday, August 04, 2011 2:51 PM
>> > > To: Patches and discussions about the oe-core layer
>> > > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>> > > support for glibc recipes
>> > >
>> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
>> > > >
>> > > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>> > >
>> > > This commit message is very terse.  Why is this change necessary?
>> >
>> > Because meta-x32 layer has glibc, which needs these support files. I
>> will update the commit message in the tree.
>>
>> Can't the tclibc-glibc file go in meta-x32 as well, then?
>>
> It can go in the meta-x32 layer, but I think better place for this support file is in the meta layer. It would help avoid duplication of the code in multiple layers.

Part of the answer here is that obsolete / etc things don't belong in
the core, but in other layers that need them.  My read on things is
that we've removed glibc in favor of eglibc...

-- 
Tom

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:50 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, Aug 4, 2011 at 3:47 PM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> >> Phil Blundell
> >> Sent: Thursday, August 04, 2011 3:10 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> >> support for glibc recipes
> >>
> >> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
> >> >
> >> > > -----Original Message-----
> >> > > From: openembedded-core-bounces@lists.openembedded.org
> >> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On
> Behalf
> >> Of
> >> > > Phil Blundell
> >> > > Sent: Thursday, August 04, 2011 2:51 PM
> >> > > To: Patches and discussions about the oe-core layer
> >> > > Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the
> needed
> >> > > support for glibc recipes
> >> > >
> >> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com
> wrote:
> >> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >> > > >
> >> > > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >> > >
> >> > > This commit message is very terse.  Why is this change
> necessary?
> >> >
> >> > Because meta-x32 layer has glibc, which needs these support files.
> I
> >> will update the commit message in the tree.
> >>
> >> Can't the tclibc-glibc file go in meta-x32 as well, then?
> >>
> > It can go in the meta-x32 layer, but I think better place for this
> support file is in the meta layer. It would help avoid duplication of
> the code in multiple layers.
> 
> Part of the answer here is that obsolete / etc things don't belong in
> the core, but in other layers that need them.  My read on things is
> that we've removed glibc in favor of eglibc...

With high demand I will move the glibc file in the meta-x32 layer. I was trying to do what felt right at 1st, but I wasn't aware that eglibc is favored so much over glibc.
> 
> --
> Tom
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Richard Purdie]

On Thu, 2011-08-04 at 15:57 -0700, Kamble, Nitin A wrote:
> > > It can go in the meta-x32 layer, but I think better place for this
> > support file is in the meta layer. It would help avoid duplication of
> > the code in multiple layers.
> > 
> > Part of the answer here is that obsolete / etc things don't belong in
> > the core, but in other layers that need them.  My read on things is
> > that we've removed glibc in favor of eglibc...
> 
> With high demand I will move the glibc file in the meta-x32 layer. I
> was trying to do what felt right at 1st, but I wasn't aware that
> eglibc is favored so much over glibc.

Please just place that file in the x32 layer. If you need the
PREFERRED_VERSION config, please also place that there.

Cheers,

Richard

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Khem Raj]

On 08/04/2011 03:47 PM, Kamble, Nitin A wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Phil Blundell
>> Sent: Thursday, August 04, 2011 3:10 PM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>> support for glibc recipes
>>
>> On Thu, 2011-08-04 at 15:04 -0700, Kamble, Nitin A wrote:
>>>
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>> Of
>>>> Phil Blundell
>>>> Sent: Thursday, August 04, 2011 2:51 PM
>>>> To: Patches and discussions about the oe-core layer
>>>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>>>> support for glibc recipes
>>>>
>>>> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>>>>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>>>>>
>>>>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
>>>>
>>>> This commit message is very terse.  Why is this change necessary?
>>>
>>> Because meta-x32 layer has glibc, which needs these support files. I
>> will update the commit message in the tree.
>>
>> Can't the tclibc-glibc file go in meta-x32 as well, then?
>>
> It can go in the meta-x32 layer, but I think better place for this support file is in the meta layer. It would help avoid duplication of the code in multiple layers.
>

oe-core does not need it. It could be deleted.

>> p.
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Tom Rini]

On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A
<nitin.a.kamble@intel.com> wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Phil Blundell
>> Sent: Thursday, August 04, 2011 2:51 PM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>> support for glibc recipes
>>
>> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
>> >
>> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
>>
>> This commit message is very terse.  Why is this change necessary?
>
> Because meta-x32 layer has glibc, which needs these support files. I will update the commit message in the tree.

Can x32 not use eglibc?

-- 
Tom

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:49 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A
> <nitin.a.kamble@intel.com> wrote:
> >
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> >> Phil Blundell
> >> Sent: Thursday, August 04, 2011 2:51 PM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> >> support for glibc recipes
> >>
> >> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> >> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >> >
> >> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> >>
> >> This commit message is very terse.  Why is this change necessary?
> >
> > Because meta-x32 layer has glibc, which needs these support files. I
> will update the commit message in the tree.
> 
> Can x32 not use eglibc?
Not yet, x32 work is done on the glibc tip, and eglibc is not there to pick up the work.

Nitin

> 
> --
> Tom
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Khem Raj]

On 08/04/2011 03:58 PM, Kamble, Nitin A wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Tom Rini
>> Sent: Thursday, August 04, 2011 3:49 PM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>> support for glibc recipes
>>
>> On Thu, Aug 4, 2011 at 3:04 PM, Kamble, Nitin A
>> <nitin.a.kamble@intel.com>  wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: openembedded-core-bounces@lists.openembedded.org
>>>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
>> Of
>>>> Phil Blundell
>>>> Sent: Thursday, August 04, 2011 2:51 PM
>>>> To: Patches and discussions about the oe-core layer
>>>> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
>>>> support for glibc recipes
>>>>
>>>> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>>>>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>>>>>
>>>>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
>>>>
>>>> This commit message is very terse.  Why is this change necessary?
>>>
>>> Because meta-x32 layer has glibc, which needs these support files. I
>> will update the commit message in the tree.
>>
>> Can x32 not use eglibc?
> Not yet, x32 work is done on the glibc tip, and eglibc is not there to pick up the work.

glibc tip is pulled into eglibc svn trunk very frequently. So an 
eglibc_svn.bb recipe can get you what you want.

>
> Nitin
>
>>
>> --
>> Tom
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Khem Raj]

On 08/04/2011 08:01 AM, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>
> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> ---
>   meta/conf/distro/include/tclibc-glibc.inc   |   32 +++++++++++++++++++++++++++
>   meta/conf/distro/include/tcmode-default.inc |    5 ++++
>   2 files changed, 37 insertions(+), 0 deletions(-)
>   create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
>
> diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
> new file mode 100644
> index 0000000..823195c
> --- /dev/null
> +++ b/meta/conf/distro/include/tclibc-glibc.inc
> @@ -0,0 +1,32 @@
> +#
> +# glibc specific configuration
> +#
> +
> +LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or '') != '']}"

why is this specific to glibc and not eglibc ?
since glibc is deleted from metadata this file should go away too
if its for external toolchains then they could use tclibc-eglibc.inc
or tclibc-uclibc.inc as needed.

I am in favour of generally using linux-gnu extention for eglibc/glibc
based systems.

> +
> +# Add glibc to the overrides.
> +OVERRIDES =. "libc-glibc:"
> +
> +PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
> +PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= "glibc-nativesdk"
> +PREFERRED_PROVIDER_virtual/libintl ?= "glibc"
> +PREFERRED_PROVIDER_virtual/libc ?= "glibc"
> +PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "glibc-nativesdk"
> +PREFERRED_PROVIDER_virtual/libc-locale ?= "glibc-locale"
> +
> +CXXFLAGS += "-fvisibility-inlines-hidden"
> +
> +LIBC_DEPENDENCIES = "\
> +    libsegfault \
> +    glibc \
> +    glibc-dbg \
> +    glibc-dev \
> +    glibc-utils \
> +    glibc-thread-db \
> +    glibc-localedata-i18n \
> +    glibc-gconv-ibm850 \
> +    glibc-gconv-cp1252 \
> +    glibc-gconv-iso8859-1 \
> +    glibc-gconv-iso8859-15 \
> +    locale-base-en-gb \
> +    "
> diff --git a/meta/conf/distro/include/tcmode-default.inc b/meta/conf/distro/include/tcmode-default.inc
> index 0d0af38..5f66c9e 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?= "${BINUVERSION}"
>   PREFERRED_VERSION_binutils-cross-canadian ?= "${BINUVERSION}"
>   PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}"
>   PREFERRED_VERSION_linux-libc-headers-nativesdk ?= "${LINUXLIBCVERSION}"
> +PREFERRED_VERSION_glibc ?= "${GLIBCVERSION}"
> +PREFERRED_VERSION_glibc-locale ?= "${GLIBCVERSION}"
> +PREFERRED_VERSION_glibc-nativesdk ?= "${GLIBCVERSION}"
> +PREFERRED_VERSION_glibc-initial ?= "${GLIBCVERSION}"
> +PREFERRED_VERSION_glibc-initial-nativesdk ?= "${GLIBCVERSION}"
>   PREFERRED_VERSION_eglibc                   ?= "${EGLIBCVERSION}"
>   PREFERRED_VERSION_eglibc-locale            ?= "${EGLIBCVERSION}"
>   PREFERRED_VERSION_eglibc-nativesdk         ?= "${EGLIBCVERSION}"

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Khem Raj
> Sent: Thursday, August 04, 2011 4:19 PM
> To: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed
> support for glibc recipes
> 
> On 08/04/2011 08:01 AM, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> > ---
> >   meta/conf/distro/include/tclibc-glibc.inc   |   32
> +++++++++++++++++++++++++++
> >   meta/conf/distro/include/tcmode-default.inc |    5 ++++
> >   2 files changed, 37 insertions(+), 0 deletions(-)
> >   create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
> >
> > diff --git a/meta/conf/distro/include/tclibc-glibc.inc
> b/meta/conf/distro/include/tclibc-glibc.inc
> > new file mode 100644
> > index 0000000..823195c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/tclibc-glibc.inc
> > @@ -0,0 +1,32 @@
> > +#
> > +# glibc specific configuration
> > +#
> > +
> > +LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or
> '') != '']}"
> 
> why is this specific to glibc and not eglibc ?

I think that is for multilib. I did not do any changes to the tclibc-glibc.inc files. I just got back the last version before deletion.

> since glibc is deleted from metadata this file should go away too
> if its for external toolchains then they could use tclibc-eglibc.inc
> or tclibc-uclibc.inc as needed.


> 
> I am in favour of generally using linux-gnu extention for eglibc/glibc
> based systems.
> 
> > +
> > +# Add glibc to the overrides.
> > +OVERRIDES =. "libc-glibc:"
> > +
> > +PREFERRED_PROVIDER_virtual/libiconv ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libiconv-nativesdk ?= "glibc-nativesdk"
> > +PREFERRED_PROVIDER_virtual/libintl ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libc ?= "glibc"
> > +PREFERRED_PROVIDER_virtual/libc-nativesdk ?= "glibc-nativesdk"
> > +PREFERRED_PROVIDER_virtual/libc-locale ?= "glibc-locale"
> > +
> > +CXXFLAGS += "-fvisibility-inlines-hidden"
> > +
> > +LIBC_DEPENDENCIES = "\
> > +    libsegfault \
> > +    glibc \
> > +    glibc-dbg \
> > +    glibc-dev \
> > +    glibc-utils \
> > +    glibc-thread-db \
> > +    glibc-localedata-i18n \
> > +    glibc-gconv-ibm850 \
> > +    glibc-gconv-cp1252 \
> > +    glibc-gconv-iso8859-1 \
> > +    glibc-gconv-iso8859-15 \
> > +    locale-base-en-gb \
> > +    "
> > diff --git a/meta/conf/distro/include/tcmode-default.inc
> b/meta/conf/distro/include/tcmode-default.inc
> > index 0d0af38..5f66c9e 100644
> > --- a/meta/conf/distro/include/tcmode-default.inc
> > +++ b/meta/conf/distro/include/tcmode-default.inc
> > @@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?=
> "${BINUVERSION}"
> >   PREFERRED_VERSION_binutils-cross-canadian ?= "${BINUVERSION}"
> >   PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}"
> >   PREFERRED_VERSION_linux-libc-headers-nativesdk ?=
> "${LINUXLIBCVERSION}"
> > +PREFERRED_VERSION_glibc ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-locale ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-nativesdk ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-initial ?= "${GLIBCVERSION}"
> > +PREFERRED_VERSION_glibc-initial-nativesdk ?= "${GLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc                   ?= "${EGLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc-locale            ?= "${EGLIBCVERSION}"
> >   PREFERRED_VERSION_eglibc-nativesdk         ?= "${EGLIBCVERSION}"
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes

[Richard Purdie]

On Thu, 2011-08-04 at 16:18 -0700, Khem Raj wrote:
> On 08/04/2011 08:01 AM, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> > ---
> >   meta/conf/distro/include/tclibc-glibc.inc   |   32 +++++++++++++++++++++++++++
> >   meta/conf/distro/include/tcmode-default.inc |    5 ++++
> >   2 files changed, 37 insertions(+), 0 deletions(-)
> >   create mode 100644 meta/conf/distro/include/tclibc-glibc.inc
> >
> > diff --git a/meta/conf/distro/include/tclibc-glibc.inc b/meta/conf/distro/include/tclibc-glibc.inc
> > new file mode 100644
> > index 0000000..823195c
> > --- /dev/null
> > +++ b/meta/conf/distro/include/tclibc-glibc.inc
> > @@ -0,0 +1,32 @@
> > +#
> > +# glibc specific configuration
> > +#
> > +
> > +LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or '') != '']}"
> 
> why is this specific to glibc and not eglibc ?

eglibc has the same code.

> since glibc is deleted from metadata this file should go away too
> if its for external toolchains then they could use tclibc-eglibc.inc
> or tclibc-uclibc.inc as needed.
> 
> I am in favour of generally using linux-gnu extention for eglibc/glibc
> based systems.

I think it should be up to the user. We've ensured the recent changes
don't change the defaults, you can certainly use linux-gnu if you want
(but it will cause issues as not everything accepts that format as
things stand iirc).

Cheers,

Richard

[PATCH 05/10] toolchain-scripts & other classes: add TARGET_LD_ARCH & TARGET_AS_ARCH vars

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

This is comming from x32 need to pass special parameters to ld & as.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/classes/allarch.bbclass           |    2 ++
 meta/classes/cross-canadian.bbclass    |    2 ++
 meta/classes/cross.bbclass             |    2 ++
 meta/classes/crosssdk.bbclass          |    2 ++
 meta/classes/native.bbclass            |   10 +++++++---
 meta/classes/nativesdk.bbclass         |    4 ++++
 meta/classes/toolchain-scripts.bbclass |    9 +++++----
 meta/conf/bitbake.conf                 |   23 +++++++++++++++++------
 8 files changed, 41 insertions(+), 13 deletions(-)

diff --git a/meta/classes/allarch.bbclass b/meta/classes/allarch.bbclass
index 26fca70..a2f8179 100644
--- a/meta/classes/allarch.bbclass
+++ b/meta/classes/allarch.bbclass
@@ -12,4 +12,6 @@ INHIBIT_DEFAULT_DEPS = "1"
 TARGET_ARCH = "allarch"
 TARGET_OS = "linux"
 TARGET_CC_ARCH = "none"
+TARGET_LD_ARCH = "none"
+TARGET_AS_ARCH = "none"
 PACKAGE_EXTRA_ARCHS = ""
diff --git a/meta/classes/cross-canadian.bbclass b/meta/classes/cross-canadian.bbclass
index c878d7f..601175d 100644
--- a/meta/classes/cross-canadian.bbclass
+++ b/meta/classes/cross-canadian.bbclass
@@ -39,6 +39,8 @@ HOST_VENDOR = "${SDK_VENDOR}"
 HOST_OS = "${SDK_OS}"
 HOST_PREFIX = "${SDK_PREFIX}"
 HOST_CC_ARCH = "${SDK_CC_ARCH}"
+HOST_LD_ARCH = "${SDK_LD_ARCH}"
+HOST_AS_ARCH = "${SDK_AS_ARCH}"
 
 #assign DPKG_ARCH
 DPKG_ARCH = "${SDK_ARCH}"
diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index e19614f..519aa0d 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -11,6 +11,8 @@ HOST_VENDOR = "${BUILD_VENDOR}"
 HOST_OS = "${BUILD_OS}"
 HOST_PREFIX = "${BUILD_PREFIX}"
 HOST_CC_ARCH = "${BUILD_CC_ARCH}"
+HOST_LD_ARCH = "${BUILD_LD_ARCH}"
+HOST_AS_ARCH = "${BUILD_AS_ARCH}"
 
 STAGING_DIR_HOST = "${STAGING_DIR}/${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
 
diff --git a/meta/classes/crosssdk.bbclass b/meta/classes/crosssdk.bbclass
index a2e5a22..5cfa43b 100644
--- a/meta/classes/crosssdk.bbclass
+++ b/meta/classes/crosssdk.bbclass
@@ -9,6 +9,8 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_LD_ARCH = "${SDK_LD_ARCH}"
+TARGET_AS_ARCH = "${SDK_AS_ARCH}"
 TARGET_FPU = ""
 
 target_libdir = "${SDKPATHNATIVE}${libdir_nativesdk}"
diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 00f7b9f..9a41f19 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -24,6 +24,8 @@ TARGET_OS = "${BUILD_OS}"
 TARGET_VENDOR = "${BUILD_VENDOR}"
 TARGET_PREFIX = "${BUILD_PREFIX}"
 TARGET_CC_ARCH = "${BUILD_CC_ARCH}"
+TARGET_LD_ARCH = "${BUILD_LD_ARCH}"
+TARGET_AS_ARCH = "${BUILD_AS_ARCH}"
 TARGET_FPU = ""
 
 HOST_ARCH = "${BUILD_ARCH}"
@@ -31,6 +33,8 @@ HOST_OS = "${BUILD_OS}"
 HOST_VENDOR = "${BUILD_VENDOR}"
 HOST_PREFIX = "${BUILD_PREFIX}"
 HOST_CC_ARCH = "${BUILD_CC_ARCH}"
+HOST_LD_ARCH = "${BUILD_LD_ARCH}"
+HOST_AS_ARCH = "${BUILD_AS_ARCH}"
 
 CPPFLAGS = "${BUILD_CPPFLAGS}"
 CFLAGS = "${BUILD_CFLAGS}"
@@ -50,11 +54,11 @@ export CONFIG_SITE = ""
 export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}"
 export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}"
 export F77 = "${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}"
-export CPP = "${HOST_PREFIX}gcc -E"
-export LD = "${HOST_PREFIX}ld"
+export CPP = "${HOST_PREFIX}gcc ${HOST_CC_ARCH} -E"
+export LD = "${HOST_PREFIX}ld ${HOST_LD_ARCH} "
 export CCLD = "${CC}"
 export AR = "${HOST_PREFIX}ar"
-export AS = "${HOST_PREFIX}as"
+export AS = "${HOST_PREFIX}as ${HOST_AS_ARCH}"
 export RANLIB = "${HOST_PREFIX}ranlib"
 export STRIP = "${HOST_PREFIX}strip"
 
diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index de7a883..152d053 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -24,6 +24,8 @@ HOST_VENDOR = "${SDK_VENDOR}"
 HOST_OS = "${SDK_OS}"
 HOST_PREFIX = "${SDK_PREFIX}"
 HOST_CC_ARCH = "${SDK_CC_ARCH}"
+HOST_LD_ARCH = "${SDK_LD_ARCH}"
+HOST_AS_ARCH = "${SDK_AS_ARCH}"
 #HOST_SYS = "${HOST_ARCH}${TARGET_VENDOR}-${HOST_OS}"
 
 TARGET_ARCH = "${SDK_ARCH}"
@@ -31,6 +33,8 @@ TARGET_VENDOR = "${SDK_VENDOR}"
 TARGET_OS = "${SDK_OS}"
 TARGET_PREFIX = "${SDK_PREFIX}"
 TARGET_CC_ARCH = "${SDK_CC_ARCH}"
+TARGET_LD_ARCH = "${SDK_LD_ARCH}"
+TARGET_AS_ARCH = "${SDK_AS_ARCH}"
 TARGET_FPU = ""
 
 CPPFLAGS = "${BUILDSDK_CPPFLAGS}"
diff --git a/meta/classes/toolchain-scripts.bbclass b/meta/classes/toolchain-scripts.bbclass
index fe11e72..f7b52be 100644
--- a/meta/classes/toolchain-scripts.bbclass
+++ b/meta/classes/toolchain-scripts.bbclass
@@ -24,8 +24,8 @@ toolchain_create_sdk_env_script () {
 	fi
 	echo 'export CFLAGS="${TARGET_CC_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
 	echo 'export CXXFLAGS="${TARGET_CC_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
-	echo 'export LDFLAGS="--sysroot=${SDKTARGETSYSROOT}"' >> $script
-	echo 'export CPPFLAGS="--sysroot=${SDKTARGETSYSROOT}"' >> $script
+	echo 'export LDFLAGS="${TARGET_LD_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
+	echo 'export CPPFLAGS="${TARGET_CC_ARCH} --sysroot=${SDKTARGETSYSROOT}"' >> $script
 	echo 'export OECORE_NATIVE_SYSROOT="${SDKPATHNATIVE}"' >> $script
 	echo 'export OECORE_TARGET_SYSROOT="${SDKTARGETSYSROOT}"' >> $script
 	echo 'export OECORE_ACLOCAL_OPTS="-I ${SDKPATHNATIVE}/usr/share/aclocal"' >> $script
@@ -59,6 +59,7 @@ toolchain_create_tree_env_script () {
 	fi
 	echo 'export CFLAGS="${TARGET_CC_ARCH}"' >> $script
 	echo 'export CXXFLAGS="${TARGET_CC_ARCH}"' >> $script
+	echo 'export LDFLAGS="${TARGET_LD_ARCH}"' >> $script
 	echo 'export OECORE_NATIVE_SYSROOT="${STAGING_DIR_NATIVE}"' >> $script
 	echo 'export OECORE_TARGET_SYSROOT="${STAGING_DIR_TARGET}"' >> $script
 	echo 'export OECORE_ACLOCAL_OPTS="-I ${STAGING_DIR_NATIVE}/usr/share/aclocal"' >> $script
@@ -91,8 +92,8 @@ toolchain_create_sdk_env_script_for_installer () {
 	fi
 	echo 'export CFLAGS="${TARGET_CC_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
 	echo 'export CXXFLAGS="${TARGET_CC_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
-	echo 'export LDFLAGS="--sysroot=##SDKTARGETSYSROOT##"' >> $script
-	echo 'export CPPFLAGS="--sysroot=##SDKTARGETSYSROOT##"' >> $script
+	echo 'export LDFLAGS="${TARGET_LD_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
+	echo 'export CPPFLAGS="${TARGET_CC_ARCH} --sysroot=##SDKTARGETSYSROOT##"' >> $script
 	echo 'export OECORE_NATIVE_SYSROOT="${SDKPATHNATIVE}"' >> $script
 	echo 'export OECORE_TARGET_SYSROOT="##SDKTARGETSYSROOT##"' >> $script
         echo 'export OECORE_ACLOCAL_OPTS="-I ${SDKPATHNATIVE}/usr/share/acloal"' >> $script
diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 6f0b42c..a8321ed 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -71,6 +71,8 @@ BUILD_VENDOR = ""
 BUILD_SYS = "${BUILD_ARCH}${BUILD_VENDOR}-${BUILD_OS}"
 BUILD_PREFIX = ""
 BUILD_CC_ARCH = ""
+BUILD_LD_ARCH = ""
+BUILD_AS_ARCH = ""
 BUILD_EXEEXT = ""
 
 HOST_ARCH = "${TARGET_ARCH}"
@@ -79,10 +81,14 @@ HOST_VENDOR = "${TARGET_VENDOR}"
 HOST_SYS = "${HOST_ARCH}${HOST_VENDOR}-${HOST_OS}"
 HOST_PREFIX = "${TARGET_PREFIX}"
 HOST_CC_ARCH = "${TARGET_CC_ARCH}"
+HOST_LD_ARCH = "${TARGET_LD_ARCH}"
+HOST_AS_ARCH = "${TARGET_AS_ARCH}"
 HOST_EXEEXT = ""
 
 TUNE_ARCH ??= "INVALID"
 TUNE_CCARGS ??= ""
+TUNE_LDARGS ??= ""
+TUNE_ASARGS ??= ""
 TUNE_FEATURES ??= "${TUNE_FEATURES_tune-${DEFAULTTUNE}}"
 LIBCEXTENSION ??= ""
 ABIEXTENSION ??= ""
@@ -93,6 +99,8 @@ TARGET_VENDOR = "-oe"
 TARGET_SYS = "${TARGET_ARCH}${TARGET_VENDOR}${@['-' + bb.data.getVar('TARGET_OS', d, 1), ''][bb.data.getVar('TARGET_OS', d, 1) == ('' or 'custom')]}"
 TARGET_PREFIX = "${TARGET_SYS}-"
 TARGET_CC_ARCH = "${TUNE_CCARGS}"
+TARGET_LD_ARCH = "${TUNE_LDARGS}"
+TARGET_AS_ARCH = "${TUNE_ASARGS}"
 
 SDK_ARCH = "${BUILD_ARCH}"
 SDK_OS = "${BUILD_OS}"
@@ -101,6 +109,8 @@ SDK_SYS = "${SDK_ARCH}${SDK_VENDOR}${@['-' + bb.data.getVar('SDK_OS', d, 1), '']
 SDK_PREFIX = "${SDK_SYS}-"
 SDK_CC_ARCH = "${BUILD_CC_ARCH}"
 SDK_PACKAGE_ARCHS = "all any noarch ${SDK_ARCH}-nativesdk"
+SDK_LD_ARCH = "${BUILD_LD_ARCH}"
+SDK_AS_ARCH = "${BUILD_AS_ARCH}"
 
 PACKAGE_ARCH = "${TUNE_PKGARCH}"
 MACHINE_ARCH = "${@[bb.data.getVar('TUNE_PKGARCH', d, 1), bb.data.getVar('MACHINE', d, 1)][bool(bb.data.getVar('MACHINE', d, 1))].replace('-', '_')}"
@@ -398,11 +408,11 @@ export CCACHE_DIR = "${TMPDIR}/ccache/${HOST_SYS}/${PN}"
 export CC = "${CCACHE}${HOST_PREFIX}gcc ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export CXX = "${CCACHE}${HOST_PREFIX}g++ ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
 export F77 = "${CCACHE}${HOST_PREFIX}g77 ${HOST_CC_ARCH}${TOOLCHAIN_OPTIONS}"
-export CPP = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS}"
-export LD = "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS}"
+export CPP = "${HOST_PREFIX}gcc -E${TOOLCHAIN_OPTIONS} ${HOST_CC_ARCH}"
+export LD = "${HOST_PREFIX}ld${TOOLCHAIN_OPTIONS} ${HOST_LD_ARCH}"
 export CCLD = "${CC}"
 export AR = "${HOST_PREFIX}ar"
-export AS = "${HOST_PREFIX}as"
+export AS = "${HOST_PREFIX}as ${HOST_AS_ARCH}"
 export RANLIB = "${HOST_PREFIX}ranlib"
 export STRIP = "${HOST_PREFIX}strip"
 export OBJCOPY = "${HOST_PREFIX}objcopy"
@@ -413,10 +423,11 @@ PYTHON = "${@sys.executable}"
 export BUILD_CC = "${CCACHE}${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
 export BUILD_CXX = "${CCACHE}${BUILD_PREFIX}g++ ${BUILD_CC_ARCH}"
 export BUILD_F77 = "${CCACHE}${BUILD_PREFIX}g77 ${BUILD_CC_ARCH}"
-export BUILD_CPP = "${BUILD_PREFIX}cpp"
-export BUILD_LD = "${BUILD_PREFIX}ld"
-export BUILD_CCLD = "${BUILD_PREFIX}gcc"
+export BUILD_CPP = "${BUILD_PREFIX}cpp ${BUILD_CC_ARCH}"
+export BUILD_LD = "${BUILD_PREFIX}ld ${BUILD_LD_ARCH}"
+export BUILD_CCLD = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
 export BUILD_AR = "${BUILD_PREFIX}ar"
+export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
 export BUILD_RANLIB = "${BUILD_PREFIX}ranlib"
 export BUILD_STRIP = "${BUILD_PREFIX}strip"
 export BUILD_NM = "${BUILD_PREFIX}nm"
-- 
1.7.6

Re: [PATCH 05/10] toolchain-scripts & other classes: add TARGET_LD_ARCH & TARGET_AS_ARCH vars

[Richard Purdie]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> This is comming from x32 need to pass special parameters to ld & as.
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
>  meta/classes/allarch.bbclass           |    2 ++
>  meta/classes/cross-canadian.bbclass    |    2 ++
>  meta/classes/cross.bbclass             |    2 ++
>  meta/classes/crosssdk.bbclass          |    2 ++
>  meta/classes/native.bbclass            |   10 +++++++---
>  meta/classes/nativesdk.bbclass         |    4 ++++
>  meta/classes/toolchain-scripts.bbclass |    9 +++++----
>  meta/conf/bitbake.conf                 |   23 +++++++++++++++++------
>  8 files changed, 41 insertions(+), 13 deletions(-)

Merged to master, thanks.

Richard

[PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

KERNEL_LD was using ${LD} in it's definition, which is not correct for
different ABIs such as x32 or i386 on x86_64 machine.

Same with KERNEL_AR var.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/classes/kernel.bbclass      |    2 +-
 meta/classes/module-base.bbclass |    4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index f2f05b1..7dc9cc6 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -47,7 +47,7 @@ TARGET_LD_KERNEL_ARCH ?= ""
 HOST_LD_KERNEL_ARCH ?= "${TARGET_LD_KERNEL_ARCH}"
 
 KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
-KERNEL_LD = "${LD}${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
+KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}${TOOLCHAIN_OPTIONS}"
 
 # Where built kernel lies in the kernel tree
 KERNEL_OUTPUT ?= "arch/${ARCH}/boot/${KERNEL_IMAGETYPE}"
diff --git a/meta/classes/module-base.bbclass b/meta/classes/module-base.bbclass
index 1a39cc1..9379bf8 100644
--- a/meta/classes/module-base.bbclass
+++ b/meta/classes/module-base.bbclass
@@ -21,8 +21,8 @@ TARGET_AR_KERNEL_ARCH ?= ""
 HOST_AR_KERNEL_ARCH ?= "${TARGET_AR_KERNEL_ARCH}"
 
 KERNEL_CC = "${CCACHE}${HOST_PREFIX}gcc${KERNEL_CCSUFFIX} ${HOST_CC_KERNEL_ARCH}"
-KERNEL_LD = "${LD}${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
-KERNEL_AR = "${AR}${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}"
+KERNEL_LD = "${HOST_PREFIX}ld${KERNEL_LDSUFFIX} ${HOST_LD_KERNEL_ARCH}"
+KERNEL_AR = "${HOST_PREFIX}ar${KERNEL_ARSUFFIX} ${HOST_AR_KERNEL_ARCH}"
 
 # kernel modules are generally machine specific
 PACKAGE_ARCH = "${MACHINE_ARCH}"
-- 
1.7.6

Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Phil Blundell]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> KERNEL_LD was using ${LD} in it's definition, which is not correct for
> different ABIs such as x32 or i386 on x86_64 machine.
> 
> Same with KERNEL_AR var.

Why is ar an issue?  That doesn't have any unusual args, does it?

p.

Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:50 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> KERNEL_LD & KERNEL_AR vars
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > KERNEL_LD was using ${LD} in it's definition, which is not correct
> for
> > different ABIs such as x32 or i386 on x86_64 machine.
> >
> > Same with KERNEL_AR var.
> 
> Why is ar an issue?  That doesn't have any unusual args, does it?
> 
> p.

No special args for ar, but The change makes definition of KERNEL_AR consistent with other definitions like KERNEL_CC & KERNEL_LD.

Nitin
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Phil Blundell]

On Thu, 2011-08-04 at 15:03 -0700, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Phil Blundell
> > Sent: Thursday, August 04, 2011 2:50 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> > KERNEL_LD & KERNEL_AR vars
> > 
> > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> > > KERNEL_LD was using ${LD} in it's definition, which is not correct
> > for
> > > different ABIs such as x32 or i386 on x86_64 machine.
> > >
> > > Same with KERNEL_AR var.
> > 
> > Why is ar an issue?  That doesn't have any unusual args, does it?
> > 
> > p.
> 
> No special args for ar, but The change makes definition of KERNEL_AR consistent with other definitions like KERNEL_CC & KERNEL_LD.

Okay, fair enough.  Please say that in the checkin message, though.  The
existing text makes it sound as though KERNEL_AR was actually broken
before.

p.

Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, August 05, 2011 12:52 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> KERNEL_LD & KERNEL_AR vars
> 
> On Thu, 2011-08-04 at 15:03 -0700, Kamble, Nitin A wrote:
> >
> > > -----Original Message-----
> > > From: openembedded-core-bounces@lists.openembedded.org
> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:50 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass:
> fix
> > > KERNEL_LD & KERNEL_AR vars
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > >
> > > > KERNEL_LD was using ${LD} in it's definition, which is not
> correct
> > > for
> > > > different ABIs such as x32 or i386 on x86_64 machine.
> > > >
> > > > Same with KERNEL_AR var.
> > >
> > > Why is ar an issue?  That doesn't have any unusual args, does it?
> > >
> > > p.
> >
> > No special args for ar, but The change makes definition of KERNEL_AR
> consistent with other definitions like KERNEL_CC & KERNEL_LD.
> 
> Okay, fair enough.  Please say that in the checkin message, though.
> The
> existing text makes it sound as though KERNEL_AR was actually broken
> before.
> 
Point noted, Changed the commit message.

Nitin

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars

[Richard Purdie]

On Fri, 2011-08-05 at 08:41 -0700, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Phil Blundell
> > Sent: Friday, August 05, 2011 12:52 AM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass: fix
> > KERNEL_LD & KERNEL_AR vars
> > 
> > On Thu, 2011-08-04 at 15:03 -0700, Kamble, Nitin A wrote:
> > >
> > > > -----Original Message-----
> > > > From: openembedded-core-bounces@lists.openembedded.org
> > > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> > Of
> > > > Phil Blundell
> > > > Sent: Thursday, August 04, 2011 2:50 PM
> > > > To: Patches and discussions about the oe-core layer
> > > > Subject: Re: [OE-core] [PATCH 06/10] kernel, module-base.bbclass:
> > fix
> > > > KERNEL_LD & KERNEL_AR vars
> > > >
> > > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > > >
> > > > > KERNEL_LD was using ${LD} in it's definition, which is not
> > correct
> > > > for
> > > > > different ABIs such as x32 or i386 on x86_64 machine.
> > > > >
> > > > > Same with KERNEL_AR var.
> > > >
> > > > Why is ar an issue?  That doesn't have any unusual args, does it?
> > > >
> > > > p.
> > >
> > > No special args for ar, but The change makes definition of KERNEL_AR
> > consistent with other definitions like KERNEL_CC & KERNEL_LD.
> > 
> > Okay, fair enough.  Please say that in the checkin message, though.
> > The
> > existing text makes it sound as though KERNEL_AR was actually broken
> > before.
>  
> Point noted, Changed the commit message.

I've merged this with an updated commit message.

Cheers,

Richard

[PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/classes/siteinfo.bbclass |   14 +++++++++++++-
 1 files changed, 13 insertions(+), 1 deletions(-)

diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
index 9dacd58..daa7946 100644
--- a/meta/classes/siteinfo.bbclass
+++ b/meta/classes/siteinfo.bbclass
@@ -42,12 +42,15 @@ def siteinfo_data(d):
         "sh4": "endian-little bit-32 sh-common",
         "sparc": "endian-big bit-32",
         "viac3": "endian-little bit-32 ix86-common",
-        "x86_64": "endian-little bit-64",
+        "x86_64": "endian-little", # bitinfo specified in targetinfo
     }
     osinfo = {
         "darwin": "common-darwin",
         "darwin9": "common-darwin",
         "linux": "common-linux common-glibc",
+        "linux-gnu32": "common-linux common-glibc",
+        "linux-gnux32": "common-linux common-glibc",
+        "linux-gnu64": "common-linux common-glibc",
         "linux-gnueabi": "common-linux common-glibc",
         "linux-gnuspe": "common-linux common-glibc",
         "linux-uclibc": "common-linux common-uclibc",
@@ -68,6 +71,15 @@ def siteinfo_data(d):
         "powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux powerpc-linux-uclibc",
         "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
         "powerpc64-linux": "powerpc-linux",
+        "x86_64-cygwin": "bit-64",
+        "x86_64-darvin": "bit-64",
+        "x86_64-darvin9": "bit-64",
+        "x86_64-linux": "bit-64",
+        "x86_64-linux-uclibc": "bit-64",
+        "x86_64-linux-gnu32": "bit-32 ix86-common",
+        "x86_64-linux-gnux32": "bit-32 ix86-common",
+        "x86_64-linux-gnu64": "bit-64 x86_64-linux",
+        "x86_64-mingw32": "bit-64",
     }
 
     hostarch = d.getVar("HOST_ARCH", True)
-- 
1.7.6

Re: [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets

[Tom Rini]

On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
>  meta/classes/siteinfo.bbclass |   14 +++++++++++++-
>  1 files changed, 13 insertions(+), 1 deletions(-)
>
> diff --git a/meta/classes/siteinfo.bbclass b/meta/classes/siteinfo.bbclass
> index 9dacd58..daa7946 100644
> --- a/meta/classes/siteinfo.bbclass
> +++ b/meta/classes/siteinfo.bbclass
> @@ -42,12 +42,15 @@ def siteinfo_data(d):
>         "sh4": "endian-little bit-32 sh-common",
>         "sparc": "endian-big bit-32",
>         "viac3": "endian-little bit-32 ix86-common",
> -        "x86_64": "endian-little bit-64",
> +        "x86_64": "endian-little", # bitinfo specified in targetinfo
>     }
>     osinfo = {
>         "darwin": "common-darwin",
>         "darwin9": "common-darwin",
>         "linux": "common-linux common-glibc",
> +        "linux-gnu32": "common-linux common-glibc",
> +        "linux-gnux32": "common-linux common-glibc",
> +        "linux-gnu64": "common-linux common-glibc",
>         "linux-gnueabi": "common-linux common-glibc",
>         "linux-gnuspe": "common-linux common-glibc",
>         "linux-uclibc": "common-linux common-uclibc",
> @@ -68,6 +71,15 @@ def siteinfo_data(d):
>         "powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux powerpc-linux-uclibc",
>         "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
>         "powerpc64-linux": "powerpc-linux",
> +        "x86_64-cygwin": "bit-64",
> +        "x86_64-darvin": "bit-64",
> +        "x86_64-darvin9": "bit-64",

You still haven't fixed this typo. It's darWin not darVin.

-- 
Tom

Re: [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:52 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 07/10] siteinfo.bbclass: add entries for
> new x86_64 ABI targets
> 
> On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> >  meta/classes/siteinfo.bbclass |   14 +++++++++++++-
> >  1 files changed, 13 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta/classes/siteinfo.bbclass
> b/meta/classes/siteinfo.bbclass
> > index 9dacd58..daa7946 100644
> > --- a/meta/classes/siteinfo.bbclass
> > +++ b/meta/classes/siteinfo.bbclass
> > @@ -42,12 +42,15 @@ def siteinfo_data(d):
> >         "sh4": "endian-little bit-32 sh-common",
> >         "sparc": "endian-big bit-32",
> >         "viac3": "endian-little bit-32 ix86-common",
> > -        "x86_64": "endian-little bit-64",
> > +        "x86_64": "endian-little", # bitinfo specified in targetinfo
> >     }
> >     osinfo = {
> >         "darwin": "common-darwin",
> >         "darwin9": "common-darwin",
> >         "linux": "common-linux common-glibc",
> > +        "linux-gnu32": "common-linux common-glibc",
> > +        "linux-gnux32": "common-linux common-glibc",
> > +        "linux-gnu64": "common-linux common-glibc",
> >         "linux-gnueabi": "common-linux common-glibc",
> >         "linux-gnuspe": "common-linux common-glibc",
> >         "linux-uclibc": "common-linux common-uclibc",
> > @@ -68,6 +71,15 @@ def siteinfo_data(d):
> >         "powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux
> powerpc-linux-uclibc",
> >         "powerpc64-linux-gnuspe": "powerpc-linux powerpc64-linux",
> >         "powerpc64-linux": "powerpc-linux",
> > +        "x86_64-cygwin": "bit-64",
> > +        "x86_64-darvin": "bit-64",
> > +        "x86_64-darvin9": "bit-64",
> 
> You still haven't fixed this typo. It's darWin not darVin.
Got it. Thanks for catching this again :)
Nitin

> 
> --
> Tom
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[PATCH 08/10] insane.bbclass: add entries for linux-gnu<ABI>

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

for x86_64 multiple ABIs now have these new names for the TARGET_OS.
Add entries for:
 linux-gnu32, linux-gnux32, linux-gnu64

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/classes/insane.bbclass |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 5fb0d98..15e7fc7 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -90,6 +90,15 @@ def package_qa_get_machine_dict():
                         "microblaze":   (47787,  0,    0,          False,         32),
                         "microblazeel": (47787,  0,    0,          True,          32),
                       },
+            "linux-gnu32" :       {
+                        "x86_64":     (62,     0,    0,          True,          32),
+                      },
+            "linux-gnux32" :       {
+                        "x86_64":     (62,     0,    0,          True,          32),
+                      },
+            "linux-gnu64" :       {
+                        "x86_64":     (62,     0,    0,          True,          64),
+                      },
        }
 
 
-- 
1.7.6

Re: [PATCH 08/10] insane.bbclass: add entries for linux-gnu<ABI>

[Richard Purdie]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> for x86_64 multiple ABIs now have these new names for the TARGET_OS.
> Add entries for:
>  linux-gnu32, linux-gnux32, linux-gnu64
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
>  meta/classes/insane.bbclass |    9 +++++++++
>  1 files changed, 9 insertions(+), 0 deletions(-)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 5fb0d98..15e7fc7 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -90,6 +90,15 @@ def package_qa_get_machine_dict():
>                          "microblaze":   (47787,  0,    0,          False,         32),
>                          "microblazeel": (47787,  0,    0,          True,          32),
>                        },
> +            "linux-gnu32" :       {
> +                        "x86_64":     (62,     0,    0,          True,          32),
> +                      },

This one doesn't make sense to me. linux-gnu32 would be i586 (arch=3)
and not arch=62?

> +            "linux-gnux32" :       {
> +                        "x86_64":     (62,     0,    0,          True,          32),
> +                      },

This one is fine.

> +            "linux-gnu64" :       {
> +                        "x86_64":     (62,     0,    0,          True,          64),
> +                      },
>         }

I'm not sure we need this either...

Cheers,

Richard

Re: [PATCH 08/10] insane.bbclass: add entries for linux-gnu<ABI>

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, August 05, 2011 9:07 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 08/10] insane.bbclass: add entries for
> linux-gnu<ABI>
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > for x86_64 multiple ABIs now have these new names for the TARGET_OS.
> > Add entries for:
> >  linux-gnu32, linux-gnux32, linux-gnu64
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> >  meta/classes/insane.bbclass |    9 +++++++++
> >  1 files changed, 9 insertions(+), 0 deletions(-)
> >
> > diff --git a/meta/classes/insane.bbclass
> b/meta/classes/insane.bbclass
> > index 5fb0d98..15e7fc7 100644
> > --- a/meta/classes/insane.bbclass
> > +++ b/meta/classes/insane.bbclass
> > @@ -90,6 +90,15 @@ def package_qa_get_machine_dict():
> >                          "microblaze":   (47787,  0,    0,
> False,         32),
> >                          "microblazeel": (47787,  0,    0,
> True,          32),
> >                        },
> > +            "linux-gnu32" :       {
> > +                        "x86_64":     (62,     0,    0,
> True,          32),
> > +                      },
> 
> This one doesn't make sense to me. linux-gnu32 would be i586 (arch=3)
> and not arch=62?
> 
> > +            "linux-gnux32" :       {
> > +                        "x86_64":     (62,     0,    0,
> True,          32),
> > +                      },
> 
> This one is fine.
> 
> > +            "linux-gnu64" :       {
> > +                        "x86_64":     (62,     0,    0,
> True,          64),
> > +                      },
> >         }
> 
> I'm not sure we need this either...

If the ABIEXTENTION is taken out for m32 & m64 tunes, then these are not needed. So I will take them out.
Thanks,
Nitin

> 
> Cheers,
> 
> Richard
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta/conf/machine/include/ia32/arch-ia32.inc |   23 ++++++++++++++++++++---
 meta/conf/machine/include/tune-core2.inc     |    4 ++++
 meta/conf/machine/include/tune-x86_64.inc    |    2 +-
 3 files changed, 25 insertions(+), 4 deletions(-)

diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc b/meta/conf/machine/include/ia32/arch-ia32.inc
index 2709440..fb527da 100644
--- a/meta/conf/machine/include/ia32/arch-ia32.inc
+++ b/meta/conf/machine/include/ia32/arch-ia32.inc
@@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
 TARGET_FPU ?= ""
 X86ARCH32 ?= "i586"
 X86ARCH64 ?= "x86_64"
+X86ARCHX32 ?= "x86_64"
 
 # ELF32 ABI
 TUNEVALID[m32] = "IA32 ELF32 standard ABI"
-TUNECONFLICTS[m32] = "m64"
+TUNECONFLICTS[m32] = "m64 mx32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "${X86ARCH32}", "" ,d)}"
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32", "" ,d)}"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
 
+# x32 ABI
+TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
+TUNECONFLICTS[mx32] = "m64 m32"
+TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "${X86ARCHX32}", "" ,d)}"
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "x32", "" ,d)}"
+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
+TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
+TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
+
 # ELF64 ABI
 TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
-TUNECONFLICT[m64] = "m32"
+TUNECONFLICT[m64] = "m32 mx32"
 TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}"
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64", "" ,d)}"
 TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"
 
 TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}"
@@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
 AVAILTUNES += "x86-64"
 TUNE_FEATURES_tune-x86-64 ?= "m64"
 BASE_LIB_tune-x86-64 ?= "lib64"
-PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
+PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
+
+AVAILTUNES += "x86-64-x32"
+TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
+BASE_LIB_tune-x86-64-x32 ?= "lib"
+PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"
diff --git a/meta/conf/machine/include/tune-core2.inc b/meta/conf/machine/include/tune-core2.inc
index 25c2226..8a4de3e 100644
--- a/meta/conf/machine/include/tune-core2.inc
+++ b/meta/conf/machine/include/tune-core2.inc
@@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?= "${TUNE_FEATURES_tune-x86-64} core2"
 BASE_LIB_tune-core2-64 ?= "lib64"
 PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2-64"
 
+AVAILTUNES += "core2-x32"
+TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32} core2"
+BASE_LIB_tune-core2-x32 ?= "lib"
+PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-x32"
diff --git a/meta/conf/machine/include/tune-x86_64.inc b/meta/conf/machine/include/tune-x86_64.inc
index 04b0f96..50f20ba 100644
--- a/meta/conf/machine/include/tune-x86_64.inc
+++ b/meta/conf/machine/include/tune-x86_64.inc
@@ -1,3 +1,3 @@
 require conf/machine/include/ia32/arch-ia32.inc
 
-DEFAULTTUNE = "x86-64"
+DEFAULTTUNE ?= "x86-64"
-- 
1.7.6

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Phil Blundell]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>  # ELF32 ABI
>  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> -TUNECONFLICTS[m32] = "m64"
> +TUNECONFLICTS[m32] = "m64 mx32"
>  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "${X86ARCH32}", "" ,d)}"
> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32", "" ,d)}"
>  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"

This is going to cause TARGET_OS to change for everyone using the i586
ABI, right?  That doesn't seem like it is either necessary or desirable,
and it isn't mentioned in the checkin comment either.

>  # ELF64 ABI
>  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> -TUNECONFLICT[m64] = "m32"
> +TUNECONFLICT[m64] = "m32 mx32"
>  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}"
> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64", "" ,d)}"
>  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"

... and likewise this for anybody using the x86-64 ABI.

> -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"

That change might well be fine, but again it isn't mentioned in the
checkin message.

> diff --git a/meta/conf/machine/include/tune-x86_64.inc b/meta/conf/machine/include/tune-x86_64.inc
> index 04b0f96..50f20ba 100644
> --- a/meta/conf/machine/include/tune-x86_64.inc
> +++ b/meta/conf/machine/include/tune-x86_64.inc
> @@ -1,3 +1,3 @@
>  require conf/machine/include/ia32/arch-ia32.inc
>  
> -DEFAULTTUNE = "x86-64"
> +DEFAULTTUNE ?= "x86-64"

This one is also not mentioned in the checkin message and looks a bit
more dubious to me.  Why is this required?

p.

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Thursday, August 04, 2011 2:57 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> >  # ELF32 ABI
> >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > -TUNECONFLICTS[m32] = "m64"
> > +TUNECONFLICTS[m32] = "m64 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "${X86ARCH32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
> "" ,d)}"
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
> "", d)}"
> 
> This is going to cause TARGET_OS to change for everyone using the i586
> ABI, right?  That doesn't seem like it is either necessary or
> desirable,
> and it isn't mentioned in the checkin comment either.

Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32. And it is also applicable for x86-64 machine set with x86 tune. This change is be needed if multiple tunes are built from the same build directory. If such situation is not important then the ABIEXTENSION part can be dropped.

> 
> >  # ELF64 ABI 
> >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > -TUNECONFLICT[m64] = "m32"
> > +TUNECONFLICT[m64] = "m32 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "${X86ARCH64}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
> "" ,d)}"
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
> "", d)}"
> 
> ... and likewise this for anybody using the x86-64 ABI.
This is similar to above.

> 
> > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> 
> That change might well be fine, but again it isn't mentioned in the
> checkin message.
This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune convention elsewhere. I will update the commit message for this.

> 
> > diff --git a/meta/conf/machine/include/tune-x86_64.inc
> b/meta/conf/machine/include/tune-x86_64.inc
> > index 04b0f96..50f20ba 100644
> > --- a/meta/conf/machine/include/tune-x86_64.inc
> > +++ b/meta/conf/machine/include/tune-x86_64.inc
> > @@ -1,3 +1,3 @@
> >  require conf/machine/include/ia32/arch-ia32.inc
> >
> > -DEFAULTTUNE = "x86-64"
> > +DEFAULTTUNE ?= "x86-64"
> 
> This one is also not mentioned in the checkin message and looks a bit
> more dubious to me.  Why is this required?
> 
It was required at one point when multilist support was quiet unstable. The reason it is done because the arch-ia32.inc file is included for both x86, tune-core, & x86-64 and setting this hard assignment, was breaking x86 or x32 targets. Not sure if it is still needed, I will check it.

> p.
> 
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> >
> > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > >  # ELF32 ABI
> > >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > > -TUNECONFLICTS[m32] = "m64"
> > > +TUNECONFLICTS[m32] = "m64 mx32"
> > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> > "${X86ARCH32}", "" ,d)}"
> > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> > "" ,d)}"
> > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> > "", d)}"
> >
> > This is going to cause TARGET_OS to change for everyone using the
> i586
> > ABI, right?  That doesn't seem like it is either necessary or
> > desirable,
> > and it isn't mentioned in the checkin comment either.
> 
> Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32.
> And it is also applicable for x86-64 machine set with x86 tune. This
> change is be needed if multiple tunes are built from the same build
> directory. If such situation is not important then the ABIEXTENSION
> part can be dropped.
> 
> >
> > >  # ELF64 ABI
> > >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > > -TUNECONFLICT[m64] = "m32"
> > > +TUNECONFLICT[m64] = "m32 mx32"
> > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> > "${X86ARCH64}", "" ,d)}"
> > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "64",
> > "" ,d)}"
> > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-
> m64",
> > "", d)}"
> >
> > ... and likewise this for anybody using the x86-64 ABI.
> This is similar to above.
> 
> >
> > > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> >
> > That change might well be fine, but again it isn't mentioned in the
> > checkin message.
> This is making this consistent with other PACKAGE_EXTRA_ARCHS_tune
> convention elsewhere. I will update the commit message for this.
> 
> >
> > > diff --git a/meta/conf/machine/include/tune-x86_64.inc
> > b/meta/conf/machine/include/tune-x86_64.inc
> > > index 04b0f96..50f20ba 100644
> > > --- a/meta/conf/machine/include/tune-x86_64.inc
> > > +++ b/meta/conf/machine/include/tune-x86_64.inc
> > > @@ -1,3 +1,3 @@
> > >  require conf/machine/include/ia32/arch-ia32.inc
> > >
> > > -DEFAULTTUNE = "x86-64"
> > > +DEFAULTTUNE ?= "x86-64"
> >
> > This one is also not mentioned in the checkin message and looks a bit
> > more dubious to me.  Why is this required?
> >
> It was required at one point when multilist support was quiet unstable.
> The reason it is done because the arch-ia32.inc file is included for
> both x86, tune-core, & x86-64 and setting this hard assignment, was
> breaking x86 or x32 targets. Not sure if it is still needed, I will
> check it.
Just checked, this is needed, when qemux86-64 machine is configured with x32 abi, when a different default tune is used.
Nitin

> 
> > p.
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Phil Blundell]

On Thu, 2011-08-04 at 15:18 -0700, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Phil Blundell
> > Sent: Thursday, August 04, 2011 2:57 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> > tune parameters
> > 
> > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > >  # ELF32 ABI
> > >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > > -TUNECONFLICTS[m32] = "m64"
> > > +TUNECONFLICTS[m32] = "m64 mx32"
> > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> > "${X86ARCH32}", "" ,d)}"
> > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
> > "" ,d)}"
> > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
> > "", d)}"
> > 
> > This is going to cause TARGET_OS to change for everyone using the i586
> > ABI, right?  That doesn't seem like it is either necessary or
> > desirable,
> > and it isn't mentioned in the checkin comment either.
> 
> Correct, this will change the TARGET_OS from linux_gnu to linux_gnu32. And it is also applicable for x86-64 machine set with x86 tune. This change is be needed if multiple tunes are built from the same build directory. If such situation is not important then the ABIEXTENSION part can be dropped.

Well, if you build i686 and x32 in the same tree they will already be
disambiguated through TARGET_ARCH.  Likewise i686 and x86-64 already
works for the same reason.  So, the only possible conflict is between
x86-64 and x32, and setting ABIEXTENSION for x32 (only) would be
sufficient to avoid that.

Though, I do wonder whether x32 ought to just have its own TARGET_ARCH
value rather than trying to disambiguate it through TARGET_OS hackery.

p.

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Phil Blundell
> Sent: Friday, August 05, 2011 12:51 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 15:18 -0700, Kamble, Nitin A wrote:
> >
> > > -----Original Message-----
> > > From: openembedded-core-bounces@lists.openembedded.org
> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> > > Phil Blundell
> > > Sent: Thursday, August 04, 2011 2:57 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32
> abi
> > > tune parameters
> > >
> > > On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > > >  # ELF32 ABI
> > > >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > > > -TUNECONFLICTS[m32] = "m64"
> > > > +TUNECONFLICTS[m32] = "m64 mx32"
> > > >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> > > "${X86ARCH32}", "" ,d)}"
> > > > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> > > "" ,d)}"
> > > >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> > > "", d)}"
> > >
> > > This is going to cause TARGET_OS to change for everyone using the
> i586
> > > ABI, right?  That doesn't seem like it is either necessary or
> > > desirable,
> > > and it isn't mentioned in the checkin comment either.
> >
> > Correct, this will change the TARGET_OS from linux_gnu to
> linux_gnu32. And it is also applicable for x86-64 machine set with x86
> tune. This change is be needed if multiple tunes are built from the
> same build directory. If such situation is not important then the
> ABIEXTENSION part can be dropped.
> 
> Well, if you build i686 and x32 in the same tree they will already be
> disambiguated through TARGET_ARCH.  Likewise i686 and x86-64 already
> works for the same reason.  So, the only possible conflict is between
> x86-64 and x32, and setting ABIEXTENSION for x32 (only) would be
> sufficient to avoid that.
> 
Now for TARGET_ARCH=x86_64 there are multiple targets, one is 64bit, another 
is x32 and yet another is 32. This is new addition due to multilib changes. 
To distinguish the these different ABI target, TARGET_OS is appended with 
the ABIEXTENSION.

> Though, I do wonder whether x32 ought to just have its own TARGET_ARCH
> value rather than trying to disambiguate it through TARGET_OS hackery.


Changing TARGET_ARCH is not correct way to handle it. Because HW/ARCH is 
not different, the difference is in the ABI of the OS. And also changing 
TARGET_ARCH would bring lot of other changes in recipes and classes in the 
Tree.

Thanks,
Nitin

> 
> p.
> 
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Phil Blundell]

On Fri, 2011-08-05 at 08:37 -0700, Kamble, Nitin A wrote:
> Changing TARGET_ARCH is not correct way to handle it. Because HW/ARCH is 
> not different, the difference is in the ABI of the OS. 

Well, I'm not entirely sure I agree with what you're saying here.  There
are at least a few precedents for encoding ABI details (eg hardfloat
parameter passing, endianness) into TARGET_ARCH, and it seems to me that
they belong there more naturally than in TARGET_OS.

p.

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Richard Purdie]

On Fri, 2011-08-05 at 16:41 +0100, Phil Blundell wrote:
> On Fri, 2011-08-05 at 08:37 -0700, Kamble, Nitin A wrote:
> > Changing TARGET_ARCH is not correct way to handle it. Because HW/ARCH is 
> > not different, the difference is in the ABI of the OS. 
> 
> Well, I'm not entirely sure I agree with what you're saying here.  There
> are at least a few precedents for encoding ABI details (eg hardfloat
> parameter passing, endianness) into TARGET_ARCH, and it seems to me that
> they belong there more naturally than in TARGET_OS.

Equally, there are several precedents for encoding ABI into TARGET_OS,
arm-gnueabi springs to mind...

It really comes down to the formats that the various magic files accept
and whilst its the regexps are lax on arm, they are less lax on x86 and
I suspect the TARGET_OS path is the one of less resistance in this case.

Even so, it shouldn't be necessary to change the default TARGET_OS.

Cheers,

Richard

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Phil Blundell]

On Fri, 2011-08-05 at 16:44 +0100, Richard Purdie wrote:
> Equally, there are several precedents for encoding ABI into TARGET_OS,
> arm-gnueabi springs to mind...
> 
> It really comes down to the formats that the various magic files accept
> and whilst its the regexps are lax on arm, they are less lax on x86 and
> I suspect the TARGET_OS path is the one of less resistance in this case.
> 
> Even so, it shouldn't be necessary to change the default TARGET_OS.

Yeah, fair enough.  I'm not terribly bothered either way about what
happens in the multilib case, but I would much prefer not to end up with
"i686-linux32" sort of things for a plain, non-multilibbed i686 build.

p.

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Richard Purdie]

On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
> 
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
>  meta/conf/machine/include/ia32/arch-ia32.inc |   23 ++++++++++++++++++++---
>  meta/conf/machine/include/tune-core2.inc     |    4 ++++
>  meta/conf/machine/include/tune-x86_64.inc    |    2 +-
>  3 files changed, 25 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc b/meta/conf/machine/include/ia32/arch-ia32.inc
> index 2709440..fb527da 100644
> --- a/meta/conf/machine/include/ia32/arch-ia32.inc
> +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
> @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
>  TARGET_FPU ?= ""
>  X86ARCH32 ?= "i586"
>  X86ARCH64 ?= "x86_64"
> +X86ARCHX32 ?= "x86_64"
>  
>  # ELF32 ABI
>  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> -TUNECONFLICTS[m32] = "m64"
> +TUNECONFLICTS[m32] = "m64 mx32"
>  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "${X86ARCH32}", "" ,d)}"
> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32", "" ,d)}"

Please drop the above line. There is no need to change that.

>  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32", "", d)}"
>  
> +# x32 ABI
> +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
> +TUNECONFLICTS[mx32] = "m64 m32"
> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "${X86ARCHX32}", "" ,d)}"
> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "x32", "" ,d)}"
> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
> +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m elf32_x86_64", "", d)}"
> +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
> +

These are fine.

>  # ELF64 ABI
>  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> -TUNECONFLICT[m64] = "m32"
> +TUNECONFLICT[m64] = "m32 mx32"
>  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "${X86ARCH64}", "" ,d)}"
> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64", "" ,d)}"

Again, please drop the above line.

>  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64", "", d)}"
>  
>  TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86", "x86_64", d)}"
> @@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
>  AVAILTUNES += "x86-64"
>  TUNE_FEATURES_tune-x86-64 ?= "m64"
>  BASE_LIB_tune-x86-64 ?= "lib64"
> -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"

That is likely wrong, please drop this piece.

> +
> +AVAILTUNES += "x86-64-x32"
> +TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
> +BASE_LIB_tune-x86-64-x32 ?= "lib"
> +PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"

And this is wrong too.

You really want:

TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"

> diff --git a/meta/conf/machine/include/tune-core2.inc b/meta/conf/machine/include/tune-core2.inc
> index 25c2226..8a4de3e 100644
> --- a/meta/conf/machine/include/tune-core2.inc
> +++ b/meta/conf/machine/include/tune-core2.inc
> @@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?= "${TUNE_FEATURES_tune-x86-64} core2"
>  BASE_LIB_tune-core2-64 ?= "lib64"
>  PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2-64"
>  
> +AVAILTUNES += "core2-x32"
> +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32} core2"
> +BASE_LIB_tune-core2-x32 ?= "lib"
> +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-x32"

PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-64-x32"

Cheers,

Richard

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Richard Purdie
> Sent: Friday, August 05, 2011 9:04 AM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> >  meta/conf/machine/include/ia32/arch-ia32.inc |   23
> ++++++++++++++++++++---
> >  meta/conf/machine/include/tune-core2.inc     |    4 ++++
> >  meta/conf/machine/include/tune-x86_64.inc    |    2 +-
> >  3 files changed, 25 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
> b/meta/conf/machine/include/ia32/arch-ia32.inc
> > index 2709440..fb527da 100644
> > --- a/meta/conf/machine/include/ia32/arch-ia32.inc
> > +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
> > @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
> >  TARGET_FPU ?= ""
> >  X86ARCH32 ?= "i586"
> >  X86ARCH64 ?= "x86_64"
> > +X86ARCHX32 ?= "x86_64"
> >
> >  # ELF32 ABI
> >  TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> > -TUNECONFLICTS[m32] = "m64"
> > +TUNECONFLICTS[m32] = "m64 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "${X86ARCH32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
> "" ,d)}"
> 
> Please drop the above line. There is no need to change that.
> 
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
> "", d)}"
> >
> > +# x32 ABI
> > +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
> > +TUNECONFLICTS[mx32] = "m64 m32"
> > +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> "${X86ARCHX32}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> "x32", "" ,d)}"
> > +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> mx32", "", d)}"
> > +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
> elf32_x86_64", "", d)}"
> > +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> x32", "", d)}"
> > +
> 
> These are fine.
> 
> >  # ELF64 ABI
> >  TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> > -TUNECONFLICT[m64] = "m32"
> > +TUNECONFLICT[m64] = "m32 mx32"
> >  TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "${X86ARCH64}", "" ,d)}"
> > +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
> "" ,d)}"
> 
> Again, please drop the above line.
> 
> >  TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
> "", d)}"
> >
> >  TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86",
> "x86_64", d)}"
> > @@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
> >  AVAILTUNES += "x86-64"
> >  TUNE_FEATURES_tune-x86-64 ?= "m64"
> >  BASE_LIB_tune-x86-64 ?= "lib64"
> > -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> 
> That is likely wrong, please drop this piece.
> 
> > +
> > +AVAILTUNES += "x86-64-x32"
> > +TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
> > +BASE_LIB_tune-x86-64-x32 ?= "lib"
> > +PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"
> 
> And this is wrong too.
> 
> You really want:
> 
> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32",
> "", d)}"
> PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
> 
> > diff --git a/meta/conf/machine/include/tune-core2.inc
> b/meta/conf/machine/include/tune-core2.inc
> > index 25c2226..8a4de3e 100644
> > --- a/meta/conf/machine/include/tune-core2.inc
> > +++ b/meta/conf/machine/include/tune-core2.inc
> > @@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?=
> "${TUNE_FEATURES_tune-x86-64} core2"
> >  BASE_LIB_tune-core2-64 ?= "lib64"
> >  PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
> 64} core2-64"
> >
> > +AVAILTUNES += "core2-x32"
> > +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}
> core2"
> > +BASE_LIB_tune-core2-x32 ?= "lib"
> > +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-
> x86-64-x32} core2-x32"
> 
> PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
> 64-x32} core2-64-x32"
> 
> Cheers,
> 
> Richard
> 
> 

Richard,
  Changed the commits according to the comments, please pull/cherry-pick again.

Thanks,
Nitin

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Saul Wold]

On 08/05/2011 11:07 AM, Kamble, Nitin A wrote:
>
>
>> -----Original Message-----
>> From: openembedded-core-bounces@lists.openembedded.org
>> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
>> Richard Purdie
>> Sent: Friday, August 05, 2011 9:04 AM
>> To: Patches and discussions about the oe-core layer
>> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
>> tune parameters
>>
>> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
>>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
>>>
>>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
>>> ---
>>>   meta/conf/machine/include/ia32/arch-ia32.inc |   23
>> ++++++++++++++++++++---
>>>   meta/conf/machine/include/tune-core2.inc     |    4 ++++
>>>   meta/conf/machine/include/tune-x86_64.inc    |    2 +-
>>>   3 files changed, 25 insertions(+), 4 deletions(-)
>>>
>>> diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
>> b/meta/conf/machine/include/ia32/arch-ia32.inc
>>> index 2709440..fb527da 100644
>>> --- a/meta/conf/machine/include/ia32/arch-ia32.inc
>>> +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
>>> @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
>>>   TARGET_FPU ?= ""
>>>   X86ARCH32 ?= "i586"
>>>   X86ARCH64 ?= "x86_64"
>>> +X86ARCHX32 ?= "x86_64"
>>>
>>>   # ELF32 ABI
>>>   TUNEVALID[m32] = "IA32 ELF32 standard ABI"
>>> -TUNECONFLICTS[m32] = "m64"
>>> +TUNECONFLICTS[m32] = "m64 mx32"
>>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
>> "${X86ARCH32}", "" ,d)}"
>>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
>> "" ,d)}"
>>
>> Please drop the above line. There is no need to change that.
>>
>>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
>> "", d)}"
>>>
>>> +# x32 ABI
>>> +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
>>> +TUNECONFLICTS[mx32] = "m64 m32"
>>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
>> "${X86ARCHX32}", "" ,d)}"
>>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
>> "x32", "" ,d)}"
>>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
>> mx32", "", d)}"
>>> +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
>> elf32_x86_64", "", d)}"
>>> +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
>> x32", "", d)}"
>>> +
>>
>> These are fine.
>>
>>>   # ELF64 ABI
>>>   TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
>>> -TUNECONFLICT[m64] = "m32"
>>> +TUNECONFLICT[m64] = "m32 mx32"
>>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
>> "${X86ARCH64}", "" ,d)}"
>>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
>> "" ,d)}"
>>
>> Again, please drop the above line.
>>
>>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
>> "", d)}"
>>>
>>>   TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86",
>> "x86_64", d)}"
>>> @@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
>>>   AVAILTUNES += "x86-64"
>>>   TUNE_FEATURES_tune-x86-64 ?= "m64"
>>>   BASE_LIB_tune-x86-64 ?= "lib64"
>>> -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
>>> +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
>>
>> That is likely wrong, please drop this piece.
>>
>>> +
>>> +AVAILTUNES += "x86-64-x32"
>>> +TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
>>> +BASE_LIB_tune-x86-64-x32 ?= "lib"
>>> +PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"
>>
>> And this is wrong too.
>>
>> You really want:
>>
>> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32",
>> "", d)}"
>> PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
>>
>>> diff --git a/meta/conf/machine/include/tune-core2.inc
>> b/meta/conf/machine/include/tune-core2.inc
>>> index 25c2226..8a4de3e 100644
>>> --- a/meta/conf/machine/include/tune-core2.inc
>>> +++ b/meta/conf/machine/include/tune-core2.inc
>>> @@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?=
>> "${TUNE_FEATURES_tune-x86-64} core2"
>>>   BASE_LIB_tune-core2-64 ?= "lib64"
>>>   PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
>> 64} core2-64"
>>>
>>> +AVAILTUNES += "core2-x32"
>>> +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}
>> core2"
>>> +BASE_LIB_tune-core2-x32 ?= "lib"
>>> +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-
>> x86-64-x32} core2-x32"
>>
>> PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
>> 64-x32} core2-64-x32"
>>
>> Cheers,
>>
>> Richard
>>
>>
>
> Richard,
>    Changed the commits according to the comments, please pull/cherry-pick again.
>
It might be best to rebase against master and resend a V2 patch set so 
it's clear to RP and other in the community what you changed.

BTW, for the layer, do you really need to pull glibc back in?  Or can 
you use eglibc from oe-core with the correct settings for x32?


Sau!

> Thanks,
> Nitin
>
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>

Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Saul Wold
> Sent: Friday, August 05, 2011 2:24 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> tune parameters
> 
> On 08/05/2011 11:07 AM, Kamble, Nitin A wrote:
> >
> >
> >> -----Original Message-----
> >> From: openembedded-core-bounces@lists.openembedded.org
> >> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf
> Of
> >> Richard Purdie
> >> Sent: Friday, August 05, 2011 9:04 AM
> >> To: Patches and discussions about the oe-core layer
> >> Subject: Re: [OE-core] [PATCH 09/10] x86 tune inc files: add x32 abi
> >> tune parameters
> >>
> >> On Thu, 2011-08-04 at 08:01 -0700, nitin.a.kamble@intel.com wrote:
> >>> From: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>>
> >>> Signed-off-by: Nitin A Kamble<nitin.a.kamble@intel.com>
> >>> ---
> >>>   meta/conf/machine/include/ia32/arch-ia32.inc |   23
> >> ++++++++++++++++++++---
> >>>   meta/conf/machine/include/tune-core2.inc     |    4 ++++
> >>>   meta/conf/machine/include/tune-x86_64.inc    |    2 +-
> >>>   3 files changed, 25 insertions(+), 4 deletions(-)
> >>>
> >>> diff --git a/meta/conf/machine/include/ia32/arch-ia32.inc
> >> b/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> index 2709440..fb527da 100644
> >>> --- a/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> +++ b/meta/conf/machine/include/ia32/arch-ia32.inc
> >>> @@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86"
> >>>   TARGET_FPU ?= ""
> >>>   X86ARCH32 ?= "i586"
> >>>   X86ARCH64 ?= "x86_64"
> >>> +X86ARCHX32 ?= "x86_64"
> >>>
> >>>   # ELF32 ABI
> >>>   TUNEVALID[m32] = "IA32 ELF32 standard ABI"
> >>> -TUNECONFLICTS[m32] = "m64"
> >>> +TUNECONFLICTS[m32] = "m64 mx32"
> >>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> >> "${X86ARCH32}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "32",
> >> "" ,d)}"
> >>
> >> Please drop the above line. There is no need to change that.
> >>
> >>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-
> m32",
> >> "", d)}"
> >>>
> >>> +# x32 ABI
> >>> +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI"
> >>> +TUNECONFLICTS[mx32] = "m64 m32"
> >>> +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> >> "${X86ARCHX32}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32",
> >> "x32", "" ,d)}"
> >>> +TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> >> mx32", "", d)}"
> >>> +TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
> >> elf32_x86_64", "", d)}"
> >>> +TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> >> x32", "", d)}"
> >>> +
> >>
> >> These are fine.
> >>
> >>>   # ELF64 ABI
> >>>   TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"
> >>> -TUNECONFLICT[m64] = "m32"
> >>> +TUNECONFLICT[m64] = "m32 mx32"
> >>>   TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> >> "${X86ARCH64}", "" ,d)}"
> >>> +ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
> "64",
> >> "" ,d)}"
> >>
> >> Again, please drop the above line.
> >>
> >>>   TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-
> m64",
> >> "", d)}"
> >>>
> >>>   TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32",
> "x86",
> >> "x86_64", d)}"
> >>> @@ -30,4 +42,9 @@ PACKAGE_EXTRA_ARCHS_tune-x86 = "x86"
> >>>   AVAILTUNES += "x86-64"
> >>>   TUNE_FEATURES_tune-x86-64 ?= "m64"
> >>>   BASE_LIB_tune-x86-64 ?= "lib64"
> >>> -PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86_64"
> >>> +PACKAGE_EXTRA_ARCHS_tune-x86-64 = "x86-64"
> >>
> >> That is likely wrong, please drop this piece.
> >>
> >>> +
> >>> +AVAILTUNES += "x86-64-x32"
> >>> +TUNE_FEATURES_tune-x86-64-x32 ?= "mx32"
> >>> +BASE_LIB_tune-x86-64-x32 ?= "lib"
> >>> +PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86-64-x32"
> >>
> >> And this is wrong too.
> >>
> >> You really want:
> >>
> >> TUNE_PKGARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-
> x32",
> >> "", d)}"
> >> PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
> >>
> >>> diff --git a/meta/conf/machine/include/tune-core2.inc
> >> b/meta/conf/machine/include/tune-core2.inc
> >>> index 25c2226..8a4de3e 100644
> >>> --- a/meta/conf/machine/include/tune-core2.inc
> >>> +++ b/meta/conf/machine/include/tune-core2.inc
> >>> @@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?=
> >> "${TUNE_FEATURES_tune-x86-64} core2"
> >>>   BASE_LIB_tune-core2-64 ?= "lib64"
> >>>   PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-
> x86-
> >> 64} core2-64"
> >>>
> >>> +AVAILTUNES += "core2-x32"
> >>> +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}
> >> core2"
> >>> +BASE_LIB_tune-core2-x32 ?= "lib"
> >>> +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-
> >> x86-64-x32} core2-x32"
> >>
> >> PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-
> x86-
> >> 64-x32} core2-64-x32"
> >>
> >> Cheers,
> >>
> >> Richard
> >>
> >>
> >
> > Richard,
> >    Changed the commits according to the comments, please pull/cherry-
> pick again.
> >
> It might be best to rebase against master and resend a V2 patch set so
> it's clear to RP and other in the community what you changed.

Ok, second patch set coming soon.
> 
> BTW, for the layer, do you really need to pull glibc back in?  Or can
> you use eglibc from oe-core with the correct settings for x32?
I will stay with glibc in the meta-x32 for now.

Thanks,
Nitin

> 
> 
> Sau!
> 
> > Thanks,
> > Nitin
> >
> >
> >
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
> >
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

[PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

So that it can be overridden by layers if needed.

Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
---
 meta-yocto/conf/local.conf.sample |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample
index 3e71b0a..4acec37 100644
--- a/meta-yocto/conf/local.conf.sample
+++ b/meta-yocto/conf/local.conf.sample
@@ -39,7 +39,7 @@ DISTRO ?= "poky"
 
 # BBMASK is a regular expression that can be used to tell BitBake to ignore
 # certain recipes.
-BBMASK = ""
+BBMASK ?= ""
 
 # EXTRA_IMAGE_FEATURES allows extra packages to be added to the generated images 
 # (Some of these are automatically added to certain image types)
-- 
1.7.6

Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[Tom Rini]

On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> From: Nitin A Kamble <nitin.a.kamble@intel.com>
>
> So that it can be overridden by layers if needed.
>
> Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> ---
>  meta-yocto/conf/local.conf.sample |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/meta-yocto/conf/local.conf.sample b/meta-yocto/conf/local.conf.sample
> index 3e71b0a..4acec37 100644
> --- a/meta-yocto/conf/local.conf.sample
> +++ b/meta-yocto/conf/local.conf.sample
> @@ -39,7 +39,7 @@ DISTRO ?= "poky"
>
>  # BBMASK is a regular expression that can be used to tell BitBake to ignore
>  # certain recipes.
> -BBMASK = ""
> +BBMASK ?= ""
>
>  # EXTRA_IMAGE_FEATURES allows extra packages to be added to the generated images
>  # (Some of these are automatically added to certain image types)

In oe.dev we just dropped this from local.conf iirc since a real
assignmnet was overriding a useful setting we provided.  IMHO, we
should do the same here (or at least comment it out).

-- 
Tom

Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[Kamble, Nitin A]

> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> Tom Rini
> Sent: Thursday, August 04, 2011 3:53 PM
> To: Patches and discussions about the oe-core layer
> Subject: Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK
> assignment weak
> 
> On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> >
> > So that it can be overridden by layers if needed.
> >
> > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > ---
> >  meta-yocto/conf/local.conf.sample |    2 +-
> >  1 files changed, 1 insertions(+), 1 deletions(-)
> >
> > diff --git a/meta-yocto/conf/local.conf.sample b/meta-
> yocto/conf/local.conf.sample
> > index 3e71b0a..4acec37 100644
> > --- a/meta-yocto/conf/local.conf.sample
> > +++ b/meta-yocto/conf/local.conf.sample
> > @@ -39,7 +39,7 @@ DISTRO ?= "poky"
> >
> >  # BBMASK is a regular expression that can be used to tell BitBake to
> ignore
> >  # certain recipes.
> > -BBMASK = ""
> > +BBMASK ?= ""
> >
> >  # EXTRA_IMAGE_FEATURES allows extra packages to be added to the
> generated images
> >  # (Some of these are automatically added to certain image types)
> 
> In oe.dev we just dropped this from local.conf iirc since a real
> assignmnet was overriding a useful setting we provided.  IMHO, we
> should do the same here (or at least comment it out).

I agree. We should comment it out.
> 
> --
> Tom
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[Richard Purdie]

On Thu, 2011-08-04 at 15:54 -0700, Kamble, Nitin A wrote:
> 
> > -----Original Message-----
> > From: openembedded-core-bounces@lists.openembedded.org
> > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > Tom Rini
> > Sent: Thursday, August 04, 2011 3:53 PM
> > To: Patches and discussions about the oe-core layer
> > Subject: Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK
> > assignment weak
> > 
> > On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > >
> > > So that it can be overridden by layers if needed.
> > >
> > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > ---
> > >  meta-yocto/conf/local.conf.sample |    2 +-
> > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > >
> > > diff --git a/meta-yocto/conf/local.conf.sample b/meta-
> > yocto/conf/local.conf.sample
> > > index 3e71b0a..4acec37 100644
> > > --- a/meta-yocto/conf/local.conf.sample
> > > +++ b/meta-yocto/conf/local.conf.sample
> > > @@ -39,7 +39,7 @@ DISTRO ?= "poky"
> > >
> > >  # BBMASK is a regular expression that can be used to tell BitBake to
> > ignore
> > >  # certain recipes.
> > > -BBMASK = ""
> > > +BBMASK ?= ""
> > >
> > >  # EXTRA_IMAGE_FEATURES allows extra packages to be added to the
> > generated images
> > >  # (Some of these are automatically added to certain image types)
> > 
> > In oe.dev we just dropped this from local.conf iirc since a real
> > assignmnet was overriding a useful setting we provided.  IMHO, we
> > should do the same here (or at least comment it out).
> 
> I agree. We should comment it out.

I agree too.

Cheers,

Richard

Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak

[Richard Purdie]

On Fri, 2011-08-05 at 17:07 +0100, Richard Purdie wrote:
> On Thu, 2011-08-04 at 15:54 -0700, Kamble, Nitin A wrote:
> > 
> > > -----Original Message-----
> > > From: openembedded-core-bounces@lists.openembedded.org
> > > [mailto:openembedded-core-bounces@lists.openembedded.org] On Behalf Of
> > > Tom Rini
> > > Sent: Thursday, August 04, 2011 3:53 PM
> > > To: Patches and discussions about the oe-core layer
> > > Subject: Re: [OE-core] [PATCH 10/10] local.conf.sample: make BBMASK
> > > assignment weak
> > > 
> > > On Thu, Aug 4, 2011 at 8:01 AM,  <nitin.a.kamble@intel.com> wrote:
> > > > From: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > >
> > > > So that it can be overridden by layers if needed.
> > > >
> > > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com>
> > > > ---
> > > >  meta-yocto/conf/local.conf.sample |    2 +-
> > > >  1 files changed, 1 insertions(+), 1 deletions(-)
> > > >
> > > > diff --git a/meta-yocto/conf/local.conf.sample b/meta-
> > > yocto/conf/local.conf.sample
> > > > index 3e71b0a..4acec37 100644
> > > > --- a/meta-yocto/conf/local.conf.sample
> > > > +++ b/meta-yocto/conf/local.conf.sample
> > > > @@ -39,7 +39,7 @@ DISTRO ?= "poky"
> > > >
> > > >  # BBMASK is a regular expression that can be used to tell BitBake to
> > > ignore
> > > >  # certain recipes.
> > > > -BBMASK = ""
> > > > +BBMASK ?= ""
> > > >
> > > >  # EXTRA_IMAGE_FEATURES allows extra packages to be added to the
> > > generated images
> > > >  # (Some of these are automatically added to certain image types)
> > > 
> > > In oe.dev we just dropped this from local.conf iirc since a real
> > > assignmnet was overriding a useful setting we provided.  IMHO, we
> > > should do the same here (or at least comment it out).
> > 
> > I agree. We should comment it out.
> 
> I agree too.

To save more respin and so forth I went ahead and merged that change.

Cheers,

Richard