On 6/30/19 4:04 PM, Richard Purdie wrote:
On Fri, 2019-06-28 at 20:15 +0800, Robert Yang wrote:
Fixed:
MACHINE = "qemux86-64"
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "x86"
PREFERRED_VERSION_lttng-modules = "2.10.10+git%"
$ bitbake world
NOTE: preferred version 2.10.10+git% of lttng-modules not available
(for item lib32-lttng-modules)
NOTE: versions of lttng-modules available: 2.10.10
ERROR: Multiple versions of lttng-modules are due to be built
(/path/to/lttng-modules_2.10.10.bb
virtual:devupstream:target:/path/to/lttng-modules_2.10.10.bb). Only
one version of a given PN should be built in any given build. You
likely need to set PREFERRED_VERSION_lttng-modules to select the
correct version or don't depend on multiple versions.
This is because 2.10.10+git% will be built for non-multilib lttng-
modules since
the PREFERRED_VERSION is set, but this version doesn't provide
lib32-lttng-modules, so 2.10.10 will be built, then the error
happens.
Bitbake can't extend an extended recipe, for example:
virtual:multilib:lib32:virtual:devupstream:target
Or in a reverse order:
virtual:devupstream:target:virtual:multilib:lib32
So disable devupstream when multilib is enabled.
Signed-off-by: Robert Yang <[email protected]>
---
meta/classes/devupstream.bbclass | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/meta/classes/devupstream.bbclass
b/meta/classes/devupstream.bbclass
index 7780c54..25403da 100644
--- a/meta/classes/devupstream.bbclass
+++ b/meta/classes/devupstream.bbclass
@@ -19,6 +19,12 @@
CLASSOVERRIDE .= ":class-devupstream"
python devupstream_virtclass_handler () {
+ # bitbake can't extend an extended recipe, for example:
+ # virtual:multilib:lib32:virtual:devupstream:target
+ # So disable devupstream when multilib is enabled.
+ if d.getVar('MULTILIBS'):
+ raise bb.parse.SkipRecipe("Disable devupstream when multilib
is enabled")
+
# Do nothing if this is inherited, as it's for BBCLASSEXTEND
if "devupstream" not in (d.getVar('BBCLASSEXTEND') or ""):
bb.error("Don't inherit devupstream, use BBCLASSEXTEND")
This is a bit of a serious problem with devupstream as it means we
can't rely upon it for default recipes. We need to file a bug about
this and find a way to fix it, perhaps teaching multilib about
devupstream so it can set BBCLASSEXTEND accordingly.
I filed a bug and assigned it you:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=13424
After more investigations, it seems that we should modify
ast.py:multi_finalize(), although I file the bug in oe-core product.
// Robert
Cheers,
Richard
--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core
