Hi Martin,
Here is a new patch which can fix allarch's mutilib dependencies issues,
can you see any potential problems with this patch, please ?
Subject: [PATCH] multilib.bbclass: extend allarch recipes
Extend allarch recipes, this can fix multilib dependencies issues, for
example:
$ bitbake lib32-run-postinsts
No 64 bit recipes should be built, but the fact was *no 32 bit* recipes
were built, this was because "bitbake lib32-run-postinsts" was the same as
"bitbake run-postinsts" since we didn't extend allarch recipes.
Extend allarch recipes just as allarch packagegroups will fix the
problem.
Signed-off-by: Robert Yang <liezhi.y...@windriver.com>
---
meta/classes/multilib.bbclass | 4 ----
meta/classes/multilib_global.bbclass | 4 +---
meta/classes/package.bbclass | 6 ------
3 files changed, 1 insertion(+), 13 deletions(-)
diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 75e91fa..514588e 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -46,10 +46,6 @@ python multilib_virtclass_handler () {
if bb.data.inherits_class('nativesdk', e.data) or
bb.data.inherits_class('crosssdk', e.data):
raise bb.parse.SkipPackage("We can't extend nativesdk recipes")
- if bb.data.inherits_class('allarch', e.data) and not
bb.data.inherits_class('packagegroup', e.data):
- raise bb.parse.SkipPackage("Don't extend allarch recipes which are not
packagegroups")
-
-
# Expand this since this won't work correctly once we set a multilib into
place
e.data.setVar("ALL_MULTILIB_PACKAGE_ARCHS",
e.data.getVar("ALL_MULTILIB_PACKAGE_ARCHS", True))
diff --git a/meta/classes/multilib_global.bbclass
b/meta/classes/multilib_global.bbclass
index 67dc72b..2c115d5 100644
--- a/meta/classes/multilib_global.bbclass
+++ b/meta/classes/multilib_global.bbclass
@@ -143,9 +143,7 @@ python multilib_virtclass_handler_global () {
if isinstance(e, bb.event.RecipeParsed) and not variant:
if bb.data.inherits_class('kernel', e.data) or \
- bb.data.inherits_class('module-base', e.data) or \
- (bb.data.inherits_class('allarch', e.data) and\
- not bb.data.inherits_class('packagegroup', e.data)):
+ bb.data.inherits_class('module-base', e.data):
variants = (e.data.getVar("MULTILIB_VARIANTS", True) or "").split()
import oe.classextend
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index c51a4e8..697b4d2 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1294,9 +1294,6 @@ python emit_pkgdata() {
if bb.data.inherits_class('kernel', d) or
bb.data.inherits_class('module-base', d):
write_extra_pkgs(variants, pn, packages, pkgdatadir)
- if (bb.data.inherits_class('allarch', d) and not
bb.data.inherits_class('packagegroup', d)):
- write_extra_pkgs(global_variants, pn, packages, pkgdatadir)
-
workdir = d.getVar('WORKDIR', True)
for pkg in packages.split():
@@ -1377,9 +1374,6 @@ python emit_pkgdata() {
if bb.data.inherits_class('kernel', d) or
bb.data.inherits_class('module-base', d):
write_extra_runtime_pkgs(variants, packages, pkgdatadir)
- if bb.data.inherits_class('allarch', d) and not
bb.data.inherits_class('packagegroup', d):
- write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
-
bb.utils.unlockfile(lf)
}
emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse
${PKGDESTWORK}/runtime-rprovides"
--
1.7.9.5
// Robert
On 01/07/2016 08:55 PM, Martin Jansa wrote:
On Thu, Jan 07, 2016 at 12:16:44PM +0000, Phil Blundell wrote:
On Wed, 2016-01-06 at 23:45 -0800, Robert Yang wrote:
liberation-fonts inherit fontcache which would depend on fontconfig,
and fontconfig is not allarch, so that liberation-fonts can't be
allarch.
This doesn't make any sense. I don't think allarch is, or ever has
been, contagious in that way. There is no good reason I can think of
to require that all the dependencies of an allarch package should
themselves be allarch. Indeed, if we did require this then it would
probably mean that virtually no packages could legitimately be allarch.
Current implementation requires that, because if there is dependency on
TUNE_PKGARCH or MACHINE_ARCH recipe, then this "allarch" recipe will be
rebuilt (or at least different archive is unpacked from sstate) every
single time you switch MACHINE.
That's why there is SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS and
SIGGEN_EXCLUDERECIPES_ABISAFE for sstate code to skip some dependencies
like this - but that doesn't remove the dependency only says that the
allarch recipe doesn't need to be rebuilt when the dependency signature
was modified.
Marking recipe as allarch incorrectly is worse than leaving it
TUNE_PKGARCH, because as TUNE_PKGARCH it's rebuilt once per architecture
and the stamps are valid until next metadata change, with incorrect
allarch it's also rebuilt once per architecture (or MACHINE), but also
unpacked from sstate every time you change the MACHINE (even when the
resulting packages end in the same directory with the same filename -
except when PRservice changes the last number in EXTENDPRAUTO with each
MACHINE change).
--
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
