Adjust default distrovars
cover Adjust default distrovars
These changes make sure that uclibc based images still build and some tasks do not get added forcibly to distros
Pull URL: git://git.openembedded.org/openembedded-core-contrib
Branch: kraj/default-distro
Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/default-distro
Thanks,
Khem Raj <[email protected]>
---
Khem Raj (2):
default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and
DISTRO_EXTRA_RRECOMMENDS
tclibc-uclibc.inc: Append -uclibc only to target recipes
meta/conf/distro/include/default-distrovars.inc | 3 --- meta/conf/distro/include/tclibc-uclibc.inc | 5 ++--- 2 files changed, 2 insertions(+), 6 deletions(-)
Signature · 1 line
1.7.4.1
PATCH 1/2 default-distrovars.inc: Do not add DISTRO_EXTRA_RDEPENDS and DISTRO_EXTRA_RRECOMMENDS
We otherwise get these added to image dependencies in distributions and they may not want it but would like to use those variables
--- meta/conf/distro/include/default-distrovars.inc | 3 --- 1 files changed, 0 insertions(+), 3 deletions(-)
meta/conf/distro/include/default-distrovars.inc +0 -3
@@ -14,9 +14,6 @@ LOCALE_UTF8_ONLY ?= "0" DISTRO_FEATURES ?= "alsa bluetooth ext2 irda pcmcia usbgadget usbhost wifi nfs zeroconf pci" -DISTRO_EXTRA_RDEPENDS += "task-core-boot" -DISTRO_EXTRA_RRECOMMENDS += "kernel-module-af-packet" - IMAGE_FEATURES ?= "" # This is a list of packages that are used by the build system to build the distribution, they are not
Signature · 1 line
1.7.4.1
PATCH 2/2 tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Khem RajDo not define DEPLOY_DIR_IMAGE
Append -uclibc to STAGING_DIR_TARGET only for target recipe and cross recipes
Append -uclibc to STAGING_DIR_HOST only for target recipes.
These changes make sure that we still share the native sysroot
--- meta/conf/distro/include/tclibc-uclibc.inc | 5 ++--- 1 files changed, 2 insertions(+), 3 deletions(-)
meta/conf/distro/include/tclibc-uclibc.inc +2 -3
@@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden" IMAGE_LINGUAS = "" -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images" DEPLOY_DIR_append = "-uclibc" -STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" +STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}" +STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}" SSTATE_MANIFESTS_append = "-uclibc" LIBC_DEPENDENCIES = "\
Signature · 1 line
1.7.4.1
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 6 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
I still stay we append tclibc unconditionally.
Quoted 31 lines
Signed-off-by Khem Raj <[email protected]>---
meta/conf/distro/include/tclibc-uclibc.inc | 5 ++---1 files changed, 2 insertions(+), 3 deletions(-)meta/conf/distro/include/tclibc-uclibc.inc +0
-0@@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
IMAGE_LINGUAS= ""-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
DEPLOY_DIR_append= "-uclibc"meta/conf/distro/include/tclibc-uclibc.inc +2
-2-STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" +STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}" +STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}"
SSTATE_MANIFESTS_append= "-uclibc"
LIBC_DEPENDENCIES= "\Signature · 7 lines
1.7.4.1 _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 11 lines · Koen Kooi
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 6 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
I still stay we append tclibc unconditionally.
yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
Quoted 39 lines
Quoted 28 lines
Signed-off-by Khem Raj <[email protected]>---
meta/conf/distro/include/tclibc-uclibc.inc | 5 ++---1 files changed, 2 insertions(+), 3 deletions(-)meta/conf/distro/include/tclibc-uclibc.inc +0
-0@@ -20,10 +20,9 @@ CXXFLAGS += "-fvisibility-inlines-hidden"
IMAGE_LINGUAS= ""-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"
DEPLOY_DIR_append= "-uclibc"meta/conf/distro/include/tclibc-uclibc.inc +2
-2-STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" +STAGING_DIR_TARGET_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk')]}" +STAGING_DIR_HOST_append = "${@['-uclibc', ''][oe.utils.inherits(d, 'native', 'nativesdk', 'cross', 'crosssdk')]}"
SSTATE_MANIFESTS_append= "-uclibc"
LIBC_DEPENDENCIES= "\
--
1.7.4.1Quoted 4 lines
_______________________________________________
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 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 9 lines · Khem Raj
Quoted 8 lines · Koen Kooi
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 5 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.
Quoted 5 lines
Quoted 3 lines
Quoted 1 line
These changes make sure that we still share the native sysroot
I still stay we append tclibc unconditionally.
yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
We can't depend on TCLIBC in bitbake.conf since someone still has the option of not using the standard configuration boilerplate we're providing.
Cheers,
Richard
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
Quoted 12 lines · Khem Raj
Quoted 11 lines · Koen Kooi
Quoted 10 lines
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 6 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
Quoted 7 lines
Quoted 3 lines
Quoted 1 line
I still stay we append tclibc unconditionally.
yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
We can't depend on TCLIBC in bitbake.conf since someone still has the option of not using the standard configuration boilerplate we're providing.
So we can't add TCLIBC ??= eglibc to bitbake.conf?
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 16 lines · Koen Kooi
Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
Quoted 14 lines · Khem Raj
Quoted 13 lines · Koen Kooi
Quoted 11 lines
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 6 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
I still stay we append tclibc unconditionally.
Quoted 7 lines
Quoted 5 lines
Quoted 1 line
yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
We can't depend on TCLIBC in bitbake.conf since someone still has the option of not using the standard configuration boilerplate we're providing.
So we can't add TCLIBC ??= eglibc to bitbake.conf?
No, I can just see the bug reports for uclibc building in a directory called XXX-eglibc as the user had only set the PREFERRED_PROVIDER variables.
Cheers,
Richard
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Op 16 mei 2011, om 15:50 heeft Richard Purdie het volgende geschreven:
Quoted 23 lines · Koen Kooi
Quoted 22 lines
Op 16 mei 2011, om 13:41 heeft Richard Purdie het volgende geschreven:
Quoted 19 lines · Khem Raj
Quoted 9 lines · Koen Kooi
Quoted 8 lines
Op 16 mei 2011, om 08:04 heeft Khem Raj het volgende geschreven:
Quoted 5 lines
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.Quoted 5 lines
Quoted 3 lines
Quoted 1 line
These changes make sure that we still share the native sysroot
I still stay we append tclibc unconditionally.
yes thats would simplify things if we agree to use TCLIBC in bitbake.conf
We can't depend on TCLIBC in bitbake.conf since someone still has the option of not using the standard configuration boilerplate we're providing.
Quoted 5 lines
Quoted 1 line
So we can't add TCLIBC ??= eglibc to bitbake.conf?
No, I can just see the bug reports for uclibc building in a directory called XXX-eglibc as the user had only set the
PREFERRED_PROVIDERvariables.
Do you really care about such usecases? Someone who thinks he is too smart to use the includes can 'fix' the paths himself, no?
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Khem RajQuoted 8 lines · Khem Raj
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
Signed-off-by Khem Raj <[email protected]>
The more I looked at that patch, the more holes I could see in what we were doing (and what Angstrom currently does). I started playing around with the patch below which tried to improve on that idea.
I then concluded that we might be able to do something like:
MACHINEOVERRIDES := "${MACHINE}"MACHINE_append = "-uclibc"
since what we're really trying to do in the uclibc case is replace anything MACHINE specific with something containing uclibc?
Thoughts?
Cheers,
Richard
meta/classes/sstate.bbclass +2 -2
@@ -23,7 +23,7 @@ python () { bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d) elif bb.data.inherits_class('cross', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d) elif bb.data.inherits_class('crosssdk', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) elif bb.data.inherits_class('nativesdk', d):
@@ -31,7 +31,7 @@ python () { elif bb.data.inherits_class('cross-canadian', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d) else: - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${STAGING_MACHNAME}", d), d) # These classes encode staging paths into their scripts data so can only be # reused if we manipulate the paths
meta/classes/staging.bbclass +1 -1
@@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot" do_populate_sysroot[sstate-name] = "populate-sysroot" do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}" do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/" -do_populate_sysroot[stamp-extra-info] = "${MACHINE}" +do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}" python do_populate_sysroot_setscene () { sstate_setscene(d)
meta/conf/bitbake.conf +5 -4
@@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}" # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}" +STAGING_MACHNAME ??= "${MACHINE}" +STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}" STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}" STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}" STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
@@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4" # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}" +STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}" STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap" # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
@@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel" IMAGE_ROOTFS = "${WORKDIR}/rootfs" IMAGE_BASENAME = "${PN}" -IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}" +IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}" +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}" # This option allows for a precentage overage of the actaul image size rather than a # fixed extra space
meta/conf/distro/include/tclibc-uclibc.inc +1 -5
@@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden" IMAGE_LINGUAS = "" -DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images" -DEPLOY_DIR_append = "-uclibc" -STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" -SSTATE_MANIFESTS_append = "-uclibc" +STAGING_MACHNAME = "${MACHINE}-uclibc" LIBC_DEPENDENCIES = "\ uclibc \
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 11 lines · Richard Purdie
The more I looked at that patch, the more holes I could see in what we were doing (and what Angstrom currently does). I started playing around with the patch below which tried to improve on that idea.
I then concluded that we might be able to do something like:
MACHINEOVERRIDES := "${MACHINE}"
MACHINE_append= "-uclibc"since what we're really trying to do in the uclibc case is replace anything MACHINE specific with something containing uclibc?
I think that particular change would be a bad idea for several reasons. Firstly, and perhaps most importantly, MACHINE is a primary configuration variable and having it magically change under the hood seems like it would violate the principle of least surprise. Secondly, at a practical level, this would make it hard to use MACHINE for anything other than overrides. And thirdly, at a conceptual level, the choice of libc is really nothing to do with the MACHINE.
meta/classes/sstate.bbclass
Quoted 4 lines
meta/classes/sstate.bbclass +0
-0
This patch looks good to me (and I would definitely prefer this to the solution above). The lines that you have deleted from tclibc-uclibc.inc were causing my uclibc builds to fail so I would certainly be glad to have them removed.
p.
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 21 lines · Phil Blundell
Quoted 11 lines · Richard Purdie
The more I looked at that patch, the more holes I could see in what we were doing (and what Angstrom currently does). I started playing around with the patch below which tried to improve on that idea.
I then concluded that we might be able to do something like:
MACHINEOVERRIDES := "${MACHINE}"
MACHINE_append= "-uclibc"since what we're really trying to do in the uclibc case is replace anything MACHINE specific with something containing uclibc?
I think that particular change would be a bad idea for several reasons. Firstly, and perhaps most importantly, MACHINE is a primary configuration variable and having it magically change under the hood seems like it would violate the principle of least surprise. Secondly, at a practical level, this would make it hard to use MACHINE for anything other than overrides. And thirdly, at a conceptual level, the choice of libc is really nothing to do with the MACHINE.
Quoted 9 lines
meta/classes/sstate.bbclass
Quoted 4 lines
meta/classes/sstate.bbclass +0
-0This patch looks good to me (and I would definitely prefer this to the solution above). The lines that you have deleted from tclibc-uclibc.inc were causing my uclibc builds to fail so I would certainly be glad to have them removed.
No question those lines are "wrong" but the solutions various people are using out there are "wrong" in various ways too (including what is 'working' in ansgtrom at the moment).
A solution where you replace 80% of uses of a variable with a new variable as per my proposed patch doesn't quite feel right either.
How about this idea:
TMPDIR_append = "-uclibc"
since sstate cache is deliberately outside TMPDIR so anything that can be reused between builds will automatically.
Simple, effective and addresses a lot of the bugs I can see in the other approaches...
Cheers,
Richard
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 3 lines · Richard Purdie
How about this idea:
TMPDIR_append= "-uclibc"
Hm, I'm not totally sure what this really buys us.
If the whole issue boils down to saying that you just can't share a TMPDIR between builds with competing C libraries (which sounds reasonable, since it's probably about the same thing as saying that libc selection is a DISTRO property) then it seems like something that can be fixed in the documentation. Users can just select a different TMPDIR by hand, same as they would when changing DISTROs, and it doesn't seem that there is any real need for the build system to try to work around it for them.
I'm also slightly uncomfortable with automagic TMPDIR frobbing for the same reason as MACHINE; if I set TMPDIR="foo" in my local.conf then I would have an (IMHO reasonable) expectation that the build artifacts would actually go into that directory and not some variation on the theme. I guess you could ameliorate that slightly by appending "/uclibc" so that at least you ended up using a subfolder of the chosen path, but it still doesn't seem very wholesome to me.
p.
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 7 lines · Phil Blundell
Quoted 3 lines · Richard Purdie
How about this idea:
TMPDIR_append= "-uclibc"Hm, I'm not totally sure what this really buys us.
Quoted 8 lines
If the whole issue boils down to saying that you just can't share a TMPDIR between builds with competing C libraries (which sounds reasonable, since it's probably about the same thing as saying that libc selection is a DISTRO property) then it seems like something that can be fixed in the documentation. Users can just select a different TMPDIR by hand, same as they would when changing DISTROs, and it doesn't seem that there is any real need for the build system to try to work around it for them.
Some distros want to be able to build multiple libc in the same tree in the same way multiple machines work without requiring the user to switch settings. I don't think its an unreasonable request but the implementation shouldn't impact the system too adversely. I think this fits that requirement.
Quoted 7 lines
I'm also slightly uncomfortable with automagic TMPDIR frobbing for the same reason as MACHINE; if I set TMPDIR="foo" in my local.conf then I would have an (IMHO reasonable) expectation that the build artifacts would actually go into that directory and not some variation on the theme. I guess you could ameliorate that slightly by appending "/uclibc" so that at least you ended up using a subfolder of the chosen path, but it still doesn't seem very wholesome to me.
Its not ideal but its nicer than the MACHINE workarounds IMO. We could default to turning it off and let distros choose to turn it on if they desire it too...
Cheers,
Richard
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 3 lines · Richard Purdie
Its not ideal but its nicer than the MACHINE workarounds IMO. We could default to turning it off and let distros choose to turn it on if they desire it too...
That sounds like a good plan to me. Or if it's literally just "TMPDIR_append = ...", maybe we could leave it up to the distros to set in their own config files.
p.
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Phil BlundellQuoted 7 lines · Phil Blundell
Quoted 3 lines · Richard Purdie
How about this idea:
TMPDIR_append= "-uclibc"Hm, I'm not totally sure what this really buys us.
Quoted 8 lines
If the whole issue boils down to saying that you just can't share a TMPDIR between builds with competing C libraries (which sounds reasonable, since it's probably about the same thing as saying that libc selection is a DISTRO property) then it seems like something that can be fixed in the documentation. Users can just select a different TMPDIR by hand, same as they would when changing DISTROs, and it doesn't seem that there is any real need for the build system to try to work around it for them.
there are certain parts of build process which could be shared e.g. native sysroot
and nativesdk package builds across target system library selections. and we build
a lot of native packages it will be good if they could be shared secondly the all-*-* package builds could be shared as well. Similarly multimachine build is another aspect which could share builds too having selected same C library.
Many users of oe would be development tool vendors who have BSPs for many processor boards and C libraries and they would like to have this possibility
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Richard PurdieQuoted 106 lines · Richard Purdie
Quoted 8 lines · Khem Raj
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
Signed-off-by Khem Raj <[email protected]>The more I looked at that patch, the more holes I could see in what we were doing (and what Angstrom currently does). I started playing around with the patch below which tried to improve on that idea.
I then concluded that we might be able to do something like:
MACHINEOVERRIDES := "${MACHINE}"
MACHINE_append= "-uclibc"since what we're really trying to do in the uclibc case is replace anything MACHINE specific with something containing uclibc?
Thoughts?
Cheers,
Richard
meta/classes/sstate.bbclass +0
-0@@ -23,7 +23,7 @@ python () { bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d)elif
bb.data.inherits_class('cross', d):
bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)
- bb.data.setVar('SSTATE_MANMACH',bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d)
+ bb.data.setVar('SSTATE_MANMACH',bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d) elifbb.data.inherits_class('crosssdk', d):
bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d)elifbb.data.inherits_class('nativesdk', d):meta/classes/sstate.bbclass +0
-0@@ -31,7 +31,7 @@ python () {elif
bb.data.inherits_class('cross-canadian', d):
bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d)else:
- bb.data.setVar('SSTATE_MANMACH',bb.data.expand("${MACHINE}", d), d)
+ bb.data.setVar('SSTATE_MANMACH',bb.data.expand("${STAGING_MACHNAME}", d), d)# These classes encode staging paths into their scripts data so can only be
# reused if we manipulate the pathsmeta/classes/staging.bbclass +0
-0@@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot"do_populate_sysroot[sstate-name] = "populate-sysroot" do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}" do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/"
meta/classes/staging.bbclass +1
-1-do_populate_sysroot[stamp-extra-info] = "${MACHINE}" +do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}"python
do_populate_sysroot_setscene() {
sstate_setscene(d)meta/conf/bitbake.conf +2
-1@@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}" # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}" +STAGING_MACHNAME ??= "${MACHINE}" +STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}"STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}"
STAGING_LIBDIR= "${STAGING_DIR_HOST}${libdir}"STAGING_INCDIR= "${STAGING_DIR_HOST}${includedir}"meta/conf/bitbake.conf +1
-1@@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4" # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}" +STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}"STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap"
# Setting
DEPLOY_DIRoutside of TMPDIR is helpful, when you are usingmeta/conf/bitbake.conf +0
-0@@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel"IMAGE_ROOTFS = "${WORKDIR}/rootfs"
IMAGE_BASENAME = "${PN}"meta/conf/bitbake.conf +2
-2-IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}" +IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}" +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}"# This option allows for a precentage overage of the actaul image size rather than a
# fixed extra spacemeta/conf/distro/include/tclibc-uclibc.inc +0
-0@@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden"IMAGE_LINGUAS = ""
meta/conf/distro/include/tclibc-uclibc.inc CXXFLAGS += "-fvisibility-inlines-hidden" · line 23
Quoted 6 lines
meta/conf/distro/include/tclibc-uclibc.inc +1
-5-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images" -DEPLOY_DIR_append = "-uclibc" -STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" -SSTATE_MANIFESTS_append = "-uclibc" +STAGING_MACHNAME = "${MACHINE}-uclibc"
should we use ${MACHINE}/${TCLIBC} in all those places instead of defining STAGING_MACHNAME
Quoted 5 lines
LIBC_DEPENDENCIES = "\
uclibc \
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Richard PurdieQuoted 106 lines · Richard Purdie
Quoted 8 lines · Khem Raj
Do not define
DEPLOY_DIR_IMAGE
Append -uclibc toSTAGING_DIR_TARGETonly for target recipe and cross recipes
Append -uclibc toSTAGING_DIR_HOSTonly for target recipes.These changes make sure that we still share the native sysroot
Signed-off-by Khem Raj <[email protected]>The more I looked at that patch, the more holes I could see in what we were doing (and what Angstrom currently does). I started playing around with the patch below which tried to improve on that idea.
I then concluded that we might be able to do something like:
MACHINEOVERRIDES := "${MACHINE}"
MACHINE_append= "-uclibc"since what we're really trying to do in the uclibc case is replace anything MACHINE specific with something containing uclibc?
Thoughts?
Cheers,
Richard
meta/classes/sstate.bbclass +2
-2@@ -23,7 +23,7 @@ python () { bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d) elif bb.data.inherits_class('cross', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${STAGING_MACHNAME}", d), d) elif bb.data.inherits_class('crosssdk', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) elif bb.data.inherits_class('nativesdk', d):@@ -31,7 +31,7 @@ python () { elif bb.data.inherits_class('cross-canadian', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d) else: - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${STAGING_MACHNAME}", d), d) # These classes encode staging paths into their scripts data so can only be # reused if we manipulate the pathsmeta/classes/staging.bbclass +1
-1@@ -91,7 +91,7 @@ SSTATETASKS += "do_populate_sysroot" do_populate_sysroot[sstate-name] = "populate-sysroot" do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}" do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/" -do_populate_sysroot[stamp-extra-info] = "${MACHINE}" +do_populate_sysroot[stamp-extra-info] = "${STAGING_MACHNAME}" python do_populate_sysroot_setscene () { sstate_setscene(d)meta/conf/bitbake.conf +5
-4@@ -300,7 +300,8 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}" # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}" +STAGING_MACHNAME ??= "${MACHINE}" +STAGING_DIR_HOST = "${STAGING_DIR}/${STAGING_MACHNAME}" STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}" STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}" STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"@@ -312,7 +313,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4" # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}" +STAGING_DIR_TARGET = "${STAGING_DIR}/${STAGING_MACHNAME}" STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap" # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using@@ -344,8 +345,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel" IMAGE_ROOTFS = "${WORKDIR}/rootfs" IMAGE_BASENAME = "${PN}" -IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}" +IMAGE_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}-${DATETIME}" +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${STAGING_MACHNAME}" # This option allows for a precentage overage of the actaul image size rather than a # fixed extra spacemeta/conf/distro/include/tclibc-uclibc.inc +0
-0@@ -20,11 +20,7 @@ CXXFLAGS += "-fvisibility-inlines-hidden" IMAGE_LINGUAS = ""
meta/conf/distro/include/tclibc-uclibc.inc CXXFLAGS += "-fvisibility-inlines-hidden" · line 26
Quoted 10 lines
meta/conf/distro/include/tclibc-uclibc.inc +1
-5-DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images" -DEPLOY_DIR_append = "-uclibc" -STAGING_DIR_TARGET_append = "-uclibc" -STAGING_DIR_HOST_append = "-uclibc" -SSTATE_MANIFESTS_append = "-uclibc" +STAGING_MACHNAME = "${MACHINE}-uclibc" LIBC_DEPENDENCIES = "\ uclibc \
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Signature · 1 line
-Khem
meta/classes/base.bbclass +5 -1
@@ -179,7 +179,11 @@ python base_eventhandler() { pesteruser.append(v) if pesteruser: bb.fatal('The following variable(s) were not set: %s\nPlease set them directly, or choose a MACHINE or DISTRO that sets them.' % ', '.join(pesteruser)) - + if name == "ParseCompleted": + libc = bb.data.getVar('TCLIBC', e.data, True) + virtual_libc = bb.data.getVar('PREFERRED_PROVIDER_virtual/libc', e.data, True) + if not libc or libc != virtual_libc: + bb.fatal('PREFERRED_PROVIDER_virtual/libc = %s and TCLIBC = %s, they should be same.' % (virtual_libc, libc)) if name == "ConfigParsed": generate_git_config(e)
meta/classes/sstate.bbclass +2 -2
@@ -23,7 +23,7 @@ python () { bb.data.setVar('SSTATE_PKGARCH', bb.data.getVar('BUILD_ARCH', d), d) elif bb.data.inherits_class('cross', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${BUILD_ARCH}_${MACHINE}_${TCLIBC}", d), d) elif bb.data.inherits_class('crosssdk', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${BUILD_ARCH}_${BASE_PACKAGE_ARCH}", d), d) elif bb.data.inherits_class('nativesdk', d):
@@ -31,7 +31,7 @@ python () { elif bb.data.inherits_class('cross-canadian', d): bb.data.setVar('SSTATE_PKGARCH', bb.data.expand("${SDK_ARCH}_${BASE_PACKAGE_ARCH}", d), d) else: - bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}", d), d) + bb.data.setVar('SSTATE_MANMACH', bb.data.expand("${MACHINE}_${TCLIBC}", d), d) # These classes encode staging paths into their scripts data so can only be # reused if we manipulate the paths
meta/classes/staging.bbclass +1 -0
@@ -92,6 +92,7 @@ do_populate_sysroot[sstate-name] = "populate-sysroot" do_populate_sysroot[sstate-inputdirs] = "${SYSROOT_DESTDIR}" do_populate_sysroot[sstate-outputdirs] = "${STAGING_DIR_HOST}/" do_populate_sysroot[stamp-extra-info] = "${MACHINE}" +do_populate_sysroot[stamp-extra-info] = "${TCLIBC}" python do_populate_sysroot_setscene () { sstate_setscene(d)
meta/conf/bitbake.conf +4 -4
@@ -300,7 +300,7 @@ STAGING_DATADIR_NATIVE = "${STAGING_DIR_NATIVE}${datadir_native}" # This should really be MULTIMACH_HOST_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}" +STAGING_DIR_HOST = "${STAGING_DIR}/${MACHINE}-${TCLIBC}" STAGING_BINDIR = "${STAGING_DIR_HOST}${bindir}" STAGING_LIBDIR = "${STAGING_DIR_HOST}${libdir}" STAGING_INCDIR = "${STAGING_DIR_HOST}${includedir}"
@@ -312,7 +312,7 @@ STAGING_PYDIR = "${STAGING_DIR}/lib/python2.4" # This should really be MULTIMACH_TARGET_SYS but that breaks "all" and machine # specific packages - hack around it for now. -STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}" +STAGING_DIR_TARGET = "${STAGING_DIR}/${MACHINE}-${TCLIBC}" STAGING_DIR_TCBOOTSTRAP = "${STAGING_DIR_TARGET}-tcbootstrap" # Setting DEPLOY_DIR outside of TMPDIR is helpful, when you are using
@@ -344,8 +344,8 @@ STAGING_KERNEL_DIR = "${STAGING_DIR_HOST}/kernel" IMAGE_ROOTFS = "${WORKDIR}/rootfs" IMAGE_BASENAME = "${PN}" -IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${DATETIME}" -IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}" +IMAGE_NAME = "${IMAGE_BASENAME}-${MACHINE}-${TCLIBC}-${DATETIME}" +IMAGE_LINK_NAME = "${IMAGE_BASENAME}-${MACHINE}-${TCLIBC}" # This option allows for a precentage overage of the actaul image size rather than a # fixed extra space
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 4 lines · Khem Raj
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
Cheers,
Richard
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 10 lines · Richard Purdie
Quoted 4 lines · Khem Raj
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
hmmm ok. So we delete these definitions from tclibc-uclibc.inc
DEPLOY_DIR_IMAGE = "${TMPDIR}/deploy/images"DEPLOY_DIR_append = "-uclibc"STAGING_DIR_TARGET_append = "-uclibc"STAGING_DIR_HOST_append = "-uclibc"SSTATE_MANIFESTS_append = "-uclibc"
and append define
TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"
should be enough
Quoted 5 lines
Cheers,
Richard
Signature · 1 line
-Khem
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Op 18 mei 2011, om 10:12 heeft Khem Raj het volgende geschreven:
Quoted 20 lines · Richard Purdie
Quoted 10 lines · Khem Raj
Quoted 4 lines
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
hmmm ok. So we delete these definitions from tclibc-uclibc.inc
DEPLOY_DIR_IMAGE= "${TMPDIR}/deploy/images"DEPLOY_DIR_append= "-uclibc"STAGING_DIR_TARGET_append= "-uclibc"STAGING_DIR_HOST_append= "-uclibc"SSTATE_MANIFESTS_append= "-uclibc"
Quoted 4 lines
and append define
TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"should be enough
Like this: http://patches.openembedded.org/patch/4229/ ?
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 23 lines · Koen Kooi
Op 18 mei 2011, om 10:12 heeft Khem Raj het volgende geschreven:
Quoted 20 lines · Richard Purdie
Quoted 10 lines · Khem Raj
Quoted 4 lines
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
hmmm ok. So we delete these definitions from tclibc-uclibc.inc
DEPLOY_DIR_IMAGE= "${TMPDIR}/deploy/images"DEPLOY_DIR_append= "-uclibc"STAGING_DIR_TARGET_append= "-uclibc"STAGING_DIR_HOST_append= "-uclibc"SSTATE_MANIFESTS_append= "-uclibc"
Quoted 6 lines
Quoted 4 lines
and append define
TMPDIR ?= "${TOPDIR}/tmp-${TCLIBC}"should be enough
Like this: http://patches.openembedded.org/patch/4229/ ?
yes exactly looks good to me.
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
In reply to Richard Purdie2011/5/18 Richard Purdie <[email protected]>
Quoted 6 lines · Khem Raj
Quoted 4 lines
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Quoted 7 lines
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
Note that this introduces additional build time and space to rebuild
native recipes for the different TMPDIR variants. Something which is not needed with the solution from Khem, if I properly understand things.
From a conceptual point of view it seems better to mangle the target subdir name in work (e.g. ppce300c3-oe-linux-uclibc) or introduce a subdir in TMPDIR for (e.g. ppce300c3-oe-linux/uclibc )
(actually I seem to recall that we have or had something in OE as well, something like deploy/glibc)
Frans
Re: [PATCH 2/2] tclibc-uclibc.inc: Append -uclibc only to target recipes
Quoted 14 lines · Frans Meulenbroeks
2011/5/18 Richard Purdie <[email protected]>
Quoted 12 lines · Khem Raj
Quoted 4 lines
I think we need to globalize libc variable like MACHINE or MULTIMACHINE and we could check if PREFERRED_PROVIDER_virtual/libc == TCLIBC or not in base.bbclass for sanity. Something like attached patch might be able to do it
Having assessed how many places in the system we'd need to make this kind of change I'm now of the opinion its too great. I think manipulating TMPDIR is a better cleaner solution and we should inject this there...
Quoted 3 lines
Quoted 1 line
Note that this introduces additional build time and space to rebuild
native recipes for the different TMPDIR variants. Something which is not needed with the solution from Khem, if I properly understand things.
I mentioned this elsewhere in the thread but the sstate cache directory is in TOPDIR, not TMPDIR so its shared between the builds. This means the -native recipes should not need any additional build time. There is some disk space usage but this should be minimal and disk space is comparatively cheap anyway.
Quoted 3 lines
From a conceptual point of view it seems better to mangle the target subdir name in work (e.g. ppce300c3-oe-linux-uclibc) or introduce a subdir in TMPDIR for (e.g. ppce300c3-oe-linux/uclibc )
This turns out to be quite nasty mangling as the deploy directories don't include this and would need mangling in a certain style, the sysroots need a different mangling and so does workdir, the cache directories and so on. What these all have in common is they're in TMPDIR and the native directories are pretty much the only thing we don't mangle. The exceptions to the mangling seem to work out quite ugly as in the cross case we have to "half-mangle" directories too.
Quoted 2 lines
(actually I seem to recall that we have or had something in OE as well, something like deploy/glibc)
Some of it worked ok in OE, some of it didn't and the move to a sysroot directory per machine was the straw that broke the camel's back so to speak. We need to take a step back and consider what we're trying to achieve from an overall architecture perspective and which solution makes sense.
Cheers,
Richard
Quoted 7 lines · Khem Raj
These changes make sure that uclibc based images still build and some tasks do not get added forcibly to distros
Pull URL:
git://git.openembedded.org/openembedded-core-contrib
Branch: kraj/default-distro
Browse: http://git.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=kraj/default-distro
Quoted 8 lines
Thanks,
Khem Raj<[email protected]>
---Khem Raj (2):
default-distrovars.inc: Do not addDISTRO_EXTRA_RDEPENDSand
DISTRO_EXTRA_RRECOMMENDS
Was merged into oe-core
Quoted 2 lines
tclibc-uclibc.inc: Append -uclibc only to target recipes
Clearly there has been some discussion about this one ;-)! Richard merged the TMPDIR_append.
Quoted 4 lines
meta/conf/distro/include/default-distrovars.inc | 3 --- meta/conf/distro/include/tclibc-uclibc.inc | 5 ++--- 2 files changed, 2 insertions(+), 6 deletions(-)
Thanks
Sau!