Commits to enable x32 infrastructure
cover Commits to enable x32 infrastructure
From: Nitin A Kamble <[email protected]>
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
Signature · 1 line
1.7.6
PATCH 1/10 kern-tools: extend arbitrary repository support
From: Bruce Ashfield <[email protected]>
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
--- .../kern-tools/kern-tools-native_git.bb | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1 -1
@@ -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}"
Signature · 1 line
1.7.6
PATCH 2/10 linux-yocto: process the existing branch for configuration
From: Bruce Ashfield <[email protected]>
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.
--- meta/classes/kernel-yocto.bbclass | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-)
meta/classes/kernel-yocto.bbclass +1 -8
@@ -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
Signature · 1 line
1.7.6
Re: [PATCH 02/10] linux-yocto: process the existing branch for configuration
Quoted 6 lines · On Thu, Aug 4, 2011 at 11:01 AM, <[email protected]> wrote:
From: Bruce Ashfield <[email protected]>
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
Quoted 35 lines
Signed-off-by Bruce Ashfield <[email protected]>---
meta/classes/kernel-yocto.bbclass | 9 +--------1 files changed, 1 insertions(+), 8 deletions(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
PATCH 3/10 linux-yocto: pass KMACHINE to updateme, not MACHINE
In reply to [email protected]From: Bruce Ashfield <[email protected]>
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.
--- meta/classes/kernel-yocto.bbclass | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
meta/classes/kernel-yocto.bbclass +1 -1
@@ -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
Signature · 1 line
1.7.6
Re: [PATCH 03/10] linux-yocto: pass KMACHINE to updateme, not MACHINE
Quoted 6 lines · On Thu, Aug 4, 2011 at 11:01 AM, <[email protected]> wrote:
From: Bruce Ashfield <[email protected]>
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
Quoted 28 lines
Signed-off-by Bruce Ashfield <[email protected]>---
meta/classes/kernel-yocto.bbclass | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta/classes/kernel-yocto.bbclass +0
-0@@ -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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
PATCH 4/10 glibc: bring back the needed support for glibc recipes
In reply to [email protected]From: Nitin A Kamble <[email protected]>
--- 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
meta/conf/distro/include/tclibc-glibc.inc new file +32 -0
@@ -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 \ + "
meta/conf/distro/include/tcmode-default.inc +5 -0
@@ -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}"
Signature · 1 line
1.7.6
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
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
Quoted 11 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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
Quoted 6 lines
Quoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>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
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 10 lines · Nitin A
Quoted 10 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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
Quoted 8 lines
Quoted 6 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
Quoted 3 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>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
Quoted 26 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 9 lines
Quoted 9 lines
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 recipesQuoted 2 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Quoted 9 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Nitin A Kamble <[email protected]>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.
Quoted 7 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 28 lines · Nitin A
Quoted 28 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Quoted 11 lines
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 recipesQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>
Quoted 8 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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...
Signature · 1 line
Tom
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 54 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 5 lines · Nitin A
Quoted 5 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Quoted 11 lines
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 recipesQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] OnBehalf
Quoted 5 lines
Quoted 5 lines
Of
Quoted 4 lines
Quoted 4 lines
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 theneeded
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
support for glibc recipes
On Thu, 2011-08-04 at 08:01 -0700, [email protected]
Quoted 5 lines · wrote:
Quoted 5 lines
Quoted 5 lines
Quoted 5 lines
Quoted 3 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>This commit message is very terse. Why is this change
necessary?
Quoted 2 lines
Quoted 2 lines
Quoted 2 lines
Because meta-x32 layer has glibc, which needs these support files.
I
Quoted 4 lines
Quoted 4 lines
will update the commit message in the tree.
Can't the tclibc-glibc file go in meta-x32 as well, then?
Quoted 7 lines
Quoted 1 line
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.
Quoted 8 lines
--
Tom_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 11 lines · Nitin A
Quoted 7 lines
Quoted 1 line
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
In reply to Kamble, Nitin AQuoted 28 lines · Nitin A
Quoted 28 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Quoted 11 lines
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 recipesQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>
Quoted 9 lines
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 12 lines
Quoted 7 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
In reply to Kamble, Nitin AQuoted 11 lines · Nitin A
Quoted 11 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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
Quoted 8 lines
Quoted 6 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
Quoted 3 lines
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>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?
Signature · 1 line
Tom
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 28 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 5 lines · Nitin A
Quoted 5 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 9 lines
Quoted 9 lines
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 recipesQuoted 2 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
Signed-off-by Nitin A Kamble <[email protected]>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
Quoted 8 lines
--
Tom_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
Quoted 30 lines · Nitin A
Quoted 30 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 recipesQuoted 5 lines · Nitin A
Quoted 5 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Quoted 11 lines
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 recipesQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
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.
Quoted 16 lines
Nitin
Quoted 8 lines
--
Tom_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
In reply to [email protected]Quoted 15 lines · On 08/04/2011 08:01 AM, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>--- 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
meta/conf/distro/include/tclibc-glibc.inc new file +0
-0
meta/conf/distro/include/tclibc-glibc.inc line 5
Quoted 5 lines
meta/conf/distro/include/tclibc-glibc.inc new file +5
-0@@ -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.
Quoted 43 lines
meta/conf/distro/include/tclibc-glibc.inc new file +27
-0+ +# 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 \ + "meta/conf/distro/include/tcmode-default.inc +5
-0@@ -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
Quoted 36 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Khem Raj
Sent: Thursday, August 04, 2011 4:19 PM
To: [email protected]
Subject: Re: [OE-core] [PATCH 04/10] glibc: bring back the needed support for glibc recipesQuoted 5 lines · On 08/04/2011 08:01 AM, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>--- meta/conf/distro/include/tclibc-glibc.inc | 32+++++++++++++++++++++++++++
Review
Quoted 5 lines
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
(quoted diff) +0
-0b/meta/conf/distro/include/tclibc-glibc.inc
meta/conf/distro/include/tclibc-glibc.inc line 5
Quoted 10 lines
new file mode 100644
index 0000000..823195cmeta/conf/distro/include/tclibc-glibc.inc new file +5
-0@@ -0,0 +1,32 @@ +# +# glibc specific configuration +# + +LIBCEXTENSION = "${@['', '-gnu'][(d.getVar('ABIEXTENSION', True) or'') != '']}"
Quoted 1 line
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.
Quoted 61 lines
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.
Review
Quoted 28 lines
meta/conf/distro/include/tclibc-glibc.inc new file +27
-0+ +# 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 \ + "(quoted diff) +0
-0b/meta/conf/distro/include/tcmode-default.inc
meta/conf/distro/include/tcmode-default.inc PREFERRED_VERSION_binutils-crosssdk ?=
Quoted 4 lines
index 0d0af38..5f66c9e 100644
meta/conf/distro/include/tcmode-default.inc +0
-0@@ -48,6 +48,11 @@ PREFERRED_VERSION_binutils-crosssdk ?="${BINUVERSION}"
meta/conf/distro/include/tcmode-default.inc PREFERRED_VERSION_binutils-crosssdk ?= "${BINUVERSION}"
Quoted 3 lines
meta/conf/distro/include/tcmode-default.inc +0
-0PREFERRED_VERSION_binutils-cross-canadian ?= "${BINUVERSION}" PREFERRED_VERSION_linux-libc-headers ?= "${LINUXLIBCVERSION}" PREFERRED_VERSION_linux-libc-headers-nativesdk ?="${LINUXLIBCVERSION}"
meta/conf/distro/include/tcmode-default.inc PREFERRED_VERSION_binutils-crosssdk ?= "${BINUVERSION}" · line 58
Quoted 8 lines
meta/conf/distro/include/tcmode-default.inc +5
-0+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
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 04/10] glibc: bring back the needed support for glibc recipes
In reply to Khem RajQuoted 10 lines · Khem Raj
Quoted 9 lines · On 08/04/2011 08:01 AM, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>--- 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
Quoted 13 lines
meta/conf/distro/include/tclibc-glibc.inc line 5
Quoted 11 lines
meta/conf/distro/include/tclibc-glibc.inc new file +5
-0@@ -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.
Quoted 6 lines
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 5/10 toolchain-scripts & other classes: add TARGET_LD_ARCH & TARGET_AS_ARCH vars
In reply to [email protected]From: Nitin A Kamble <[email protected]>
This is comming from x32 need to pass special parameters to ld & as.
--- 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(-)
meta/classes/allarch.bbclass +2 -0
@@ -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 = ""
meta/classes/cross-canadian.bbclass +2 -0
@@ -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}"
meta/classes/cross.bbclass +2 -0
@@ -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}"
meta/classes/crosssdk.bbclass +2 -0
@@ -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}"
meta/classes/native.bbclass +7 -3
@@ -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"
meta/classes/nativesdk.bbclass +4 -0
@@ -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}"
meta/classes/toolchain-scripts.bbclass +5 -4
@@ -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
meta/conf/bitbake.conf +17 -6
@@ -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"
Signature · 1 line
1.7.6
Richard Purdie
AppliedRe: [PATCH 05/10] toolchain-scripts & other classes: add TARGET_LD_ARCH & TARGET_AS_ARCH vars
Quoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
This is comming from x32 need to pass special parameters to ld & as.
Signed-off-by Nitin A Kamble <[email protected]>
Quoted 10 lines
--- 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 6/10 kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars
In reply to [email protected]From: Nitin A Kamble <[email protected]>
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.
--- meta/classes/kernel.bbclass | 2 +- meta/classes/module-base.bbclass | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-)
meta/classes/kernel.bbclass +1 -1
@@ -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}"
meta/classes/module-base.bbclass +2 -2
@@ -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}"
Signature · 1 line
1.7.6
Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars
Quoted 6 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
KERNEL_LDwas using ${LD} in it's definition, which is not correct for different ABIs such as x32 or i386 onx86_64machine.Same with
KERNEL_ARvar.
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
Quoted 15 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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: fixKERNEL_LD&KERNEL_ARvarsQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
KERNEL_LDwas using ${LD} in it's definition, which is not correct
Quoted 8 lines
for
Quoted 3 lines
different ABIs such as x32 or i386 on
x86_64machine.Same with
KERNEL_ARvar.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
Quoted 7 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars
Quoted 17 lines · Nitin A
Quoted 17 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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: fixKERNEL_LD&KERNEL_ARvarsQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
KERNEL_LDwas using ${LD} in it's definition, which is not correctfor
Quoted 2 lines
different ABIs such as x32 or i386 on
x86_64machine.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
Same with
KERNEL_ARvar.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_ARconsistent with other definitions likeKERNEL_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
Quoted 38 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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: fixKERNEL_LD&KERNEL_ARvarsQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 4 lines
Quoted 4 lines
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
Quoted 6 lines
Quoted 6 lines
KERNEL_LD&KERNEL_ARvarsQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
KERNEL_LDwas using ${LD} in it's definition, which is notcorrect
Quoted 9 lines
Quoted 8 lines
for
Quoted 3 lines
different ABIs such as x32 or i386 on
x86_64machine.Same with
KERNEL_ARvar.Why is ar an issue? That doesn't have any unusual args, does it?
p.
Quoted 8 lines
Quoted 1 line
No special args for ar, but The change makes definition of
KERNEL_ARconsistent 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 thoughKERNEL_ARwas actually broken before.
Point noted, Changed the commit message.
Nitin
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 06/10] kernel, module-base.bbclass: fix KERNEL_LD & KERNEL_AR vars
Quoted 38 lines · Nitin A
Quoted 38 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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: fixKERNEL_LD&KERNEL_ARvarsQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 4 lines
Quoted 4 lines
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
Quoted 6 lines
Quoted 6 lines
KERNEL_LD&KERNEL_ARvarsQuoted 3 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
KERNEL_LDwas using ${LD} in it's definition, which is notcorrect
Quoted 10 lines
Quoted 8 lines
for
Quoted 3 lines
different ABIs such as x32 or i386 on
x86_64machine.Same with
KERNEL_ARvar.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
Quoted 8 lines
Quoted 6 lines
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 thoughKERNEL_ARwas actually broken before.Point noted, Changed the commit message.
I've merged this with an updated commit message.
Cheers,
Richard
PATCH 7/10 siteinfo.bbclass: add entries for new x86_64 ABI targets
In reply to [email protected]From: Nitin A Kamble <[email protected]>
--- meta/classes/siteinfo.bbclass | 14 +++++++++++++- 1 files changed, 13 insertions(+), 1 deletions(-)
meta/classes/siteinfo.bbclass +13 -1
@@ -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)
Signature · 1 line
1.7.6
Re: [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets
Quoted 29 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>---
meta/classes/siteinfo.bbclass | 14 +++++++++++++-1 files changed, 13 insertions(+), 1 deletions(-)meta/classes/siteinfo.bbclass +4
-1@@ -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",
meta/classes/siteinfo.bbclass def siteinfo_data(d): · line 76
Quoted 6 lines
meta/classes/siteinfo.bbclass +3
-0@@ -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.
Signature · 1 line
Tom
Re: [PATCH 07/10] siteinfo.bbclass: add entries for new x86_64 ABI targets
Quoted 44 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 newx86_64ABI targetsReview
Quoted 8 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>---
meta/classes/siteinfo.bbclass | 14 +++++++++++++-1 files changed, 13 insertions(+), 1 deletions(-)(quoted diff) +0
-0b/meta/classes/siteinfo.bbclass
Quoted 21 lines
index 9dacd58..daa7946 100644
meta/classes/siteinfo.bbclass +4
-1@@ -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):Quoted 1 line
"powerpc-linux-uclibcspe": "powerpc-linux powerpc32-linux
powerpc-linux-uclibc",
Quoted 7 lines
Quoted 5 lines
"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
Quoted 8 lines
--
Tom_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
PATCH 8/10 insane.bbclass: add entries for linux-gnu<ABI>
In reply to [email protected]From: Nitin A Kamble <[email protected]>
for x86_64 multiple ABIs now have these new names for the TARGET_OS. Add entries for:
linux-gnu32, linux-gnux32, linux-gnu64
--- meta/classes/insane.bbclass | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)
meta/classes/insane.bbclass +9 -0
@@ -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), + }, }
Signature · 1 line
1.7.6
Re: [PATCH 08/10] insane.bbclass: add entries for linux-gnu<ABI>
Quoted 16 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
for
x86_64multiple ABIs now have these new names for theTARGET_OS. Add entries for:
linux-gnu32, linux-gnux32, linux-gnu64Signed-off-by Nitin A Kamble <[email protected]>--- meta/classes/insane.bbclass | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)meta/classes/insane.bbclass +0
-0
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 95
Quoted 6 lines
meta/classes/insane.bbclass +3
-0@@ -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?
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 98
Quoted 3 lines
meta/classes/insane.bbclass +3
-0+ "linux-gnux32" : { + "x86_64": (62, 0, 0, True, 32), + },
This one is fine.
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 102
Quoted 4 lines
meta/classes/insane.bbclass +3
-0+ "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>
Quoted 49 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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>Quoted 6 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
for
x86_64multiple ABIs now have these new names for theTARGET_OS. Add entries for:
linux-gnu32, linux-gnux32, linux-gnu64Review
Quoted 6 lines
Signed-off-by Nitin A Kamble <[email protected]>--- meta/classes/insane.bbclass | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-)(quoted diff) +0
-0b/meta/classes/insane.bbclass
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 90
Quoted 5 lines
index 5fb0d98..15e7fc7 100644
meta/classes/insane.bbclass +0
-0@@ -90,6 +90,15 @@ def package_qa_get_machine_dict(): "microblaze": (47787, 0, 0,False, 32),
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 91
Quoted 1 line
meta/classes/insane.bbclass +0
-0"microblazeel": (47787, 0, 0,True, 32),
meta/classes/insane.bbclass def package_qa_get_machine_dict():
Quoted 3 lines
meta/classes/insane.bbclass +2
-0}, + "linux-gnu32" : { + "x86_64": (62, 0, 0,True, 32),
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 95
Quoted 1 line
meta/classes/insane.bbclass +1
-0+ },This one doesn't make sense to me. linux-gnu32 would be i586 (arch=3) and not arch=62?
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 97
Quoted 2 lines
meta/classes/insane.bbclass +2
-0+ "linux-gnux32" : { + "x86_64": (62, 0, 0,True, 32),
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 98
Quoted 1 line
meta/classes/insane.bbclass +1
-0+ },This one is fine.
Quoted 7 lines
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 100
Quoted 2 lines
meta/classes/insane.bbclass +2
-0+ "linux-gnu64" : { + "x86_64": (62, 0, 0,True, 64),
meta/classes/insane.bbclass def package_qa_get_machine_dict(): · line 102
Quoted 2 lines
meta/classes/insane.bbclass +1
-0+ }, }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
Quoted 11 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
PATCH 9/10 x86 tune inc files: add x32 abi tune parameters
In reply to [email protected]From: Nitin A Kamble <[email protected]>
--- 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(-)
meta/conf/machine/include/ia32/arch-ia32.inc +20 -3
@@ -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"
meta/conf/machine/include/tune-core2.inc +4 -0
@@ -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"
meta/conf/machine/include/tune-x86_64.inc +1 -1
@@ -1,3 +1,3 @@ require conf/machine/include/ia32/arch-ia32.inc -DEFAULTTUNE = "x86-64" +DEFAULTTUNE ?= "x86-64"
Signature · 1 line
1.7.6
Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 16
Quoted 7 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
# ELF32 ABI
TUNEVALID[m32] = "IA32 ELF32 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +2
-1-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.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 32
Quoted 7 lines
# ELF64 ABI
TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +2
-1-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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 2 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-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.
meta/conf/machine/include/tune-x86_64.inc line 3
Quoted 9 lines
meta/conf/machine/include/tune-x86_64.inc +1
-1@@ -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
Quoted 19 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersmeta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
# ELF32 ABI
TUNEVALID[m32] = "IA32 ELF32 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICTS[m32] = "m64" +TUNECONFLICTS[m32] = "m64 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32","${X86ARCH32}", "" ,d)}"
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
Quoted 8 lines
"" ,d)}"
Quoted 1 line
TUNE_CCARGS+= "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32","", d)}"
This is going to cause
TARGET_OSto 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.
Quoted 7 lines
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 6 lines
# ELF64 ABI
TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICT[m64] = "m32" +TUNECONFLICT[m64] = "m32 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64","${X86ARCH64}", "" ,d)}"
Quoted 6 lines
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64",
"" ,d)}"
Quoted 1 line
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.
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 3 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-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.
Quoted 9 lines
Review
Quoted 2 lines
(quoted diff) +0
-0b/meta/conf/machine/include/tune-x86_64.inc
Quoted 6 lines
index 04b0f96..50f20ba 100644
meta/conf/machine/include/tune-x86_64.inc +0
-0@@ -1,3 +1,3 @@ require conf/machine/include/ia32/arch-ia32.inc
Quoted 6 lines
meta/conf/machine/include/tune-x86_64.inc line 3
Quoted 2 lines
meta/conf/machine/include/tune-x86_64.inc +1
-1-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.
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
Quoted 68 lines
Quoted 9 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
# ELF32 ABI
TUNEVALID[m32] = "IA32 ELF32 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICTS[m32] = "m64" +TUNECONFLICTS[m32] = "m64 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32","${X86ARCH32}", "" ,d)}"
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
"32",
Quoted 2 lines
"" ,d)}"
Quoted 1 line
TUNE_CCARGS+= "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
Quoted 3 lines
"", d)}"
This is going to cause
TARGET_OSto change for everyone using thei586
Quoted 3 lines
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_OSfromlinux_gnutolinux_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.Quoted 8 lines
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 6 lines
# ELF64 ABI
TUNEVALID[m64] = "IA32e (x86_64) ELF64 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICT[m64] = "m32" +TUNECONFLICT[m64] = "m32 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m64","${X86ARCH64}", "" ,d)}"
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64",
"64",
Quoted 2 lines
"" ,d)}"
Quoted 1 line
TUNE_CCARGS+= "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
Quoted 3 lines
"", d)}"
... and likewise this for anybody using the x86-64 ABI.
This is similar to above.
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 3 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-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_tuneconvention elsewhere. I will update the commit message for this.Quoted 9 lines
Review
Quoted 2 lines
(quoted diff) +0
-0b/meta/conf/machine/include/tune-x86_64.inc
Quoted 6 lines
index 04b0f96..50f20ba 100644
meta/conf/machine/include/tune-x86_64.inc +0
-0@@ -1,3 +1,3 @@ require conf/machine/include/ia32/arch-ia32.incQuoted 6 lines
meta/conf/machine/include/tune-x86_64.inc line 3
Quoted 2 lines
meta/conf/machine/include/tune-x86_64.inc +1
-1-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?
Quoted 5 lines
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
Quoted 14 lines
Quoted 9 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
In reply to Kamble, Nitin AQuoted 20 lines · Nitin A
Quoted 20 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersmeta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
# ELF32 ABI
TUNEVALID[m32] = "IA32 ELF32 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICTS[m32] = "m64" +TUNECONFLICTS[m32] = "m64 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32","${X86ARCH32}", "" ,d)}"
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32",
"" ,d)}"
Quoted 1 line
TUNE_CCARGS+= "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
Quoted 8 lines
Quoted 6 lines
"", d)}"
This is going to cause
TARGET_OSto 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_OSfromlinux_gnutolinux_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
Quoted 50 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersQuoted 4 lines · Nitin A
Quoted 4 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 4 lines
Quoted 4 lines
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 x32abi
Quoted 10 lines
Quoted 10 lines
tune parameters
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
# ELF32 ABI
TUNEVALID[m32] = "IA32 ELF32 standard ABI"meta/conf/machine/include/ia32/arch-ia32.inc +1
-1-TUNECONFLICTS[m32] = "m64" +TUNECONFLICTS[m32] = "m64 mx32" TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "m32","${X86ARCH32}", "" ,d)}"
Quoted 1 line
+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32",
"32",
Quoted 2 lines
Quoted 2 lines
"" ,d)}"
Quoted 1 line
TUNE_CCARGS+= "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
Quoted 3 lines
Quoted 3 lines
"", d)}"
This is going to cause
TARGET_OSto change for everyone using thei586
Quoted 5 lines
Quoted 3 lines
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_OSfromlinux_gnuto
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.
Quoted 6 lines
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.
Quoted 2 lines
Though, I do wonder whether x32 ought to just have its own
TARGET_ARCHvalue rather than trying to disambiguate it throughTARGET_OShackery.
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
Quoted 8 lines
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
Quoted 2 lines · Nitin A
Changing
TARGET_ARCHis 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
Quoted 8 lines · Phil Blundell
Quoted 2 lines · Nitin A
Changing
TARGET_ARCHis 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 inTARGET_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
Quoted 8 lines · Richard Purdie
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_OSpath 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
In reply to [email protected]Quoted 15 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>--- 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(-)meta/conf/machine/include/ia32/arch-ia32.inc +0
-0@@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86" TARGET_FPU ?= ""
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 15
Quoted 10 lines
meta/conf/machine/include/ia32/arch-ia32.inc +3
-1X86ARCH32 ?= "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.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 26
Quoted 11 lines
meta/conf/machine/include/ia32/arch-ia32.inc +9
-0TUNE_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.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 31
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc +2
-1# 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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 9 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1TUNE_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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 50
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +5
-0+ +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"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= "${TUNE_FEATURES_tune-x86-64} core2" · line 24
Quoted 12 lines
meta/conf/machine/include/tune-core2.inc +4
-0@@ -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
Quoted 121 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersQuoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Signed-off-by Nitin A Kamble <[email protected]>--- meta/conf/machine/include/ia32/arch-ia32.inc | 23++++++++++++++++++++---
Review
Quoted 5 lines
meta/conf/machine/include/tune-core2.inc | 4 ++++ meta/conf/machine/include/tune-x86_64.inc | 2 +- 3 files changed, 25 insertions(+), 4 deletions(-)(quoted diff) +0
-0b/meta/conf/machine/include/ia32/arch-ia32.inc
Quoted 4 lines
index 2709440..fb527da 100644
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 14
Quoted 10 lines
meta/conf/machine/include/ia32/arch-ia32.inc +2
-1@@ -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)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 15
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32","" ,d)}"
Please drop the above line. There is no need to change that.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 16
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32","", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +4
-0+# x32 ABI +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI" +TUNECONFLICTS[mx32] = "m64 m32" +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","${X86ARCHX32}", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 21
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","x32", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 22
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 23
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
elf32_x86_64", "", d)}"meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 24
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 25
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+These are fine.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1# 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)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 30
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64","" ,d)}"
Again, please drop the above line.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 31
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64","", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 32
Quoted 2 lines
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86","
x86_64", d)}"meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1@@ -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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 50
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +5
-0+ +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"Review
Quoted 1 line
(quoted diff) +0
-0b/meta/conf/machine/include/tune-core2.inc
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?=
Quoted 4 lines
index 25c2226..8a4de3e 100644
meta/conf/machine/include/tune-core2.inc +0
-0@@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?="${TUNE_FEATURES_tune-x86-64} core2"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 19
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +0
-0BASE_LIB_tune-core2-64 ?= "lib64" PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2-64"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 21
Quoted 3 lines
meta/conf/machine/include/tune-core2.inc +2
-0+AVAILTUNES += "core2-x32" +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}core2"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 23
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +2
-0+BASE_LIB_tune-core2-x32 ?= "lib" +PACKAGE_EXTRA_ARCHS_tune-core2-x32 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64-x32} core2-x32"
Quoted 8 lines
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
Quoted 124 lines · Nitin A
Quoted 124 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersQuoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>--- meta/conf/machine/include/ia32/arch-ia32.inc | 23++++++++++++++++++++---
Review
Quoted 5 lines
meta/conf/machine/include/tune-core2.inc | 4 ++++ meta/conf/machine/include/tune-x86_64.inc | 2 +- 3 files changed, 25 insertions(+), 4 deletions(-)(quoted diff) +0
-0b/meta/conf/machine/include/ia32/arch-ia32.inc
Quoted 4 lines
index 2709440..fb527da 100644
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 14
Quoted 10 lines
meta/conf/machine/include/ia32/arch-ia32.inc +2
-1@@ -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)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 15
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32", "32","" ,d)}"
Please drop the above line. There is no need to change that.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 16
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32","", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +4
-0+# x32 ABI +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI" +TUNECONFLICTS[mx32] = "m64 m32" +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","${X86ARCHX32}", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 21
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","x32", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 22
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 23
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
elf32_x86_64", "", d)}"meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 24
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 25
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+These are fine.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1# 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)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 30
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64", "64","" ,d)}"
Again, please drop the above line.
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 31
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64","", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 32
Quoted 2 lines
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32", "x86","
x86_64", d)}"meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1@@ -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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 50
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +5
-0+ +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"Review
Quoted 1 line
(quoted diff) +0
-0b/meta/conf/machine/include/tune-core2.inc
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?=
Quoted 4 lines
index 25c2226..8a4de3e 100644
meta/conf/machine/include/tune-core2.inc +0
-0@@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?="${TUNE_FEATURES_tune-x86-64} core2"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 19
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +0
-0BASE_LIB_tune-core2-64 ?= "lib64" PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-64} core2-64"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 21
Quoted 3 lines
meta/conf/machine/include/tune-core2.inc +2
-0+AVAILTUNES += "core2-x32" +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}core2"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 23
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +2
-0+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"
Quoted 9 lines
Quoted 5 lines
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!
Quoted 10 lines
Thanks,
Nitin_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 09/10] x86 tune inc files: add x32 abi tune parameters
Quoted 151 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 parametersQuoted 5 lines · Nitin A
Quoted 5 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 28 lines
Quoted 28 lines
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 parametersQuoted 5 lines · On Thu, 2011-08-04 at 08:01 -0700, [email protected] wrote:
From: Nitin A Kamble<[email protected]>
Signed-off-by Nitin A Kamble<[email protected]>--- meta/conf/machine/include/ia32/arch-ia32.inc | 23++++++++++++++++++++---
Review
Quoted 5 lines
meta/conf/machine/include/tune-core2.inc | 4 ++++ meta/conf/machine/include/tune-x86_64.inc | 2 +- 3 files changed, 25 insertions(+), 4 deletions(-)(quoted diff) +0
-0b/meta/conf/machine/include/ia32/arch-ia32.inc
Quoted 9 lines
index 2709440..fb527da 100644
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0@@ -6,17 +6,29 @@ DEFAULTTUNE ?= "x86" TARGET_FPU ?= "" X86ARCH32 ?= "i586" X86ARCH64 ?= "x86_64" +X86ARCHX32 ?= "x86_64"Quoted 7 lines
Quoted 7 lines
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1# 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)}"
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m32","32",
Quoted 5 lines
Quoted 5 lines
"" ,d)}"
Please drop the above line. There is no need to change that.
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m32", "-m32",
Quoted 19 lines
Quoted 19 lines
"", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +4
-0+# x32 ABI +TUNEVALID[mx32] = "IA32e (x86_64) ELF32 standard ABI" +TUNECONFLICTS[mx32] = "m64 m32" +TUNE_ARCH .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","${X86ARCHX32}", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 21
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "mx32","x32", "" ,d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 22
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-mx32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 23
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_LDARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-m
elf32_x86_64", "", d)}"meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 24
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+TUNE_ASARGS += "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32", "", d)}"
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86" · line 25
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+These are fine.
Quoted 7 lines
Quoted 7 lines
meta/conf/machine/include/ia32/arch-ia32.inc DEFAULTTUNE ?= "x86"
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1# 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)}"
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +1
-0+ABIEXTENSION .= "${@bb.utils.contains("TUNE_FEATURES", "m64","64",
Quoted 5 lines
Quoted 5 lines
"" ,d)}"
Again, please drop the above line.
Quoted 1 line
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_CCARGS += "${@bb.utils.contains("TUNE_FEATURES", "m64", "-m64",
Quoted 3 lines
Quoted 3 lines
"", d)}"
Quoted 2 lines
meta/conf/machine/include/ia32/arch-ia32.inc +0
-0TUNE_PKGARCH ?= "${@bb.utils.contains("TUNE_FEATURES", "m32","x86",
Quoted 18 lines
Quoted 18 lines
"
x86_64", d)}"meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 45
Quoted 6 lines
meta/conf/machine/include/ia32/arch-ia32.inc +1
-1@@ -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.
meta/conf/machine/include/ia32/arch-ia32.inc PACKAGE_EXTRA_ARCHS_tune-x86 = "x86" · line 50
Quoted 5 lines
meta/conf/machine/include/ia32/arch-ia32.inc +5
-0+ +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.
Quoted 3 lines
Quoted 3 lines
You really want:
TUNE_PKGARCH.= "${@bb.utils.contains("TUNE_FEATURES", "mx32", "-x32",
Quoted 5 lines
Quoted 5 lines
"", d)}" PACKAGE_EXTRA_ARCHS_tune-x86-64-x32 = "x86_64-x32"
Review
Quoted 1 line
(quoted diff) +0
-0b/meta/conf/machine/include/tune-core2.inc
Quoted 7 lines
Quoted 7 lines
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?=
Quoted 4 lines
index 25c2226..8a4de3e 100644
meta/conf/machine/include/tune-core2.inc +0
-0@@ -18,3 +18,7 @@ TUNE_FEATURES_tune-core2-64 ?="${TUNE_FEATURES_tune-x86-64} core2"
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +0
-0BASE_LIB_tune-core2-64 ?= "lib64" PACKAGE_EXTRA_ARCHS_tune-core2-64 = "${PACKAGE_EXTRA_ARCHS_tune-x86-
Quoted 10 lines
Quoted 10 lines
64} core2-64"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 21
Quoted 3 lines
meta/conf/machine/include/tune-core2.inc +2
-0+AVAILTUNES += "core2-x32" +TUNE_FEATURES_tune-core2-x32 ?= "${TUNE_FEATURES_tune-x86-64-x32}core2"
meta/conf/machine/include/tune-core2.inc TUNE_FEATURES_tune-core2-64 ?= · line 23
Quoted 2 lines
meta/conf/machine/include/tune-core2.inc +2
-0+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-
Quoted 8 lines
Quoted 7 lines
64-x32} core2-64-x32"
Cheers,
Richard
Quoted 6 lines
Quoted 2 lines
Richard,
Changed the commits according to the comments, please pull/cherry-pick again.
Quoted 1 line
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.
Quoted 3 lines
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
Quoted 19 lines
Sau!
Quoted 10 lines
Thanks,
Nitin_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
PATCH 10/10 local.conf.sample: make BBMASK assignment weak
In reply to [email protected]From: Nitin A Kamble <[email protected]>
So that it can be overridden by layers if needed.
--- meta-yocto/conf/local.conf.sample | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)
meta-yocto/conf/local.conf.sample +1 -1
@@ -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)
Signature · 1 line
1.7.6
Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak
Quoted 14 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
So that it can be overridden by layers if needed.
Signed-off-by Nitin A Kamble <[email protected]>---
meta-yocto/conf/local.conf.sample | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta-yocto/conf/local.conf.sample +0
-0
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 45
Quoted 8 lines
meta-yocto/conf/local.conf.sample +1
-1@@ -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).
Signature · 1 line
Tom
Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak
Quoted 34 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 weakmeta-
Quoted 10 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
So that it can be overridden by layers if needed.
Signed-off-by Nitin A Kamble <[email protected]>---
meta-yocto/conf/local.conf.sample | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta- renamed from meta-yocto/conf/local.conf.sample +0
-0yocto/conf/local.conf.sample
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 40
Quoted 6 lines
index 3e71b0a..4acec37 100644
meta-yocto/conf/local.conf.sample +0
-0@@ -39,7 +39,7 @@ DISTRO ?= "poky" # BBMASK is a regular expression that can be used to tell BitBake toignore
Quoted 4 lines
meta-yocto/conf/local.conf.sample +1
-1# certain recipes. -BBMASK = "" +BBMASK ?= ""
Quoted 7 lines
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 44
Quoted 1 line
meta-yocto/conf/local.conf.sample +0
-0# EXTRA_IMAGE_FEATURES allows extra packages to be added to thegenerated images
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 45
Quoted 1 line
meta-yocto/conf/local.conf.sample +0
-0# (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.
Quoted 8 lines
--
Tom_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 10/10] local.conf.sample: make BBMASK assignment weak
Quoted 35 lines · Nitin A
Quoted 35 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 weakmeta-
Quoted 10 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
So that it can be overridden by layers if needed.
Signed-off-by Nitin A Kamble <[email protected]>--- meta-yocto/conf/local.conf.sample | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)meta- renamed from meta-yocto/conf/local.conf.sample +0
-0yocto/conf/local.conf.sample
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 40
Quoted 6 lines
index 3e71b0a..4acec37 100644
meta-yocto/conf/local.conf.sample +0
-0@@ -39,7 +39,7 @@ DISTRO ?= "poky" # BBMASK is a regular expression that can be used to tell BitBake toignore
meta-yocto/conf/local.conf.sample DISTRO ?= "poky"
Quoted 5 lines
meta-yocto/conf/local.conf.sample +1
-1# certain recipes. -BBMASK = "" +BBMASK ?= "" # EXTRA_IMAGE_FEATURES allows extra packages to be added to thegenerated images
Quoted 7 lines
Quoted 5 lines
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 45
Quoted 1 line
meta-yocto/conf/local.conf.sample +0
-0# (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
Quoted 38 lines · Richard Purdie
Quoted 37 lines · Nitin A
Quoted 37 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] 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 weakmeta-
Quoted 10 lines · On Thu, Aug 4, 2011 at 8:01 AM, <[email protected]> wrote:
From: Nitin A Kamble <[email protected]>
So that it can be overridden by layers if needed.
Signed-off-by Nitin A Kamble <[email protected]>--- meta-yocto/conf/local.conf.sample | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-)meta- renamed from meta-yocto/conf/local.conf.sample +0
-0yocto/conf/local.conf.sample
meta-yocto/conf/local.conf.sample DISTRO ?= "poky" · line 40
Quoted 6 lines
index 3e71b0a..4acec37 100644
meta-yocto/conf/local.conf.sample +0
-0@@ -39,7 +39,7 @@ DISTRO ?= "poky" # BBMASK is a regular expression that can be used to tell BitBake toignore
meta-yocto/conf/local.conf.sample DISTRO ?= "poky"
Quoted 5 lines
meta-yocto/conf/local.conf.sample +1
-1# certain recipes. -BBMASK = "" +BBMASK ?= "" # EXTRA_IMAGE_FEATURES allows extra packages to be added to thegenerated images
Quoted 1 line
meta-yocto/conf/local.conf.sample +0
-0# (Some of these are automatically added to certain image types)
Quoted 7 lines
Quoted 5 lines
Quoted 3 lines
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
Re: [PATCH 01/10] kern-tools: extend arbitrary repository support
In reply to [email protected]Quoted 8 lines · On Thu, Aug 4, 2011 at 11:01 AM, <[email protected]> wrote:
From: Bruce Ashfield <[email protected]>
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
Quoted 28 lines
Signed-off-by Bruce Ashfield <[email protected]>---
.../kern-tools/kern-tools-native_git.bb | 2 +-1 files changed, 1 insertions(+), 1 deletions(-)meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +0
-0@@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=e2bf4415f3d8DEPENDS = "git-native guilt-native"
meta/recipes-kernel/kern-tools/kern-tools-native_git.bb +1
-1-SRCREV = "f5a915c277a37ba5949b4c0778356189e7dd9ec0" +SRCREV = "cdcb97cfea5f98003b2e0fb1a77b6d0d016a69e7"PR = r10
PV = "0.1+git${SRCPV}"--
1.7.6_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Signature · 2 lines
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"