[1/1] devupstream.bbclass: Disable devupstream when multilib is enabled

Submitted by Robert Yang on June 28, 2019, 12:15 p.m. | Patch ID: 162617

Details

Message ID 8ed4c92b7a1618a5bc2781e7af04889f65b0baa7.1561724112.git.liezhi.yang@windriver.com
State New
Headers show

Commit Message

Robert Yang June 28, 2019, 12:15 p.m.
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 <liezhi.yang@windriver.com>
---
 meta/classes/devupstream.bbclass | 6 ++++++
 1 file changed, 6 insertions(+)

Patch hide | download patch | download mbox

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")

Comments

Richard Purdie June 30, 2019, 8:04 a.m.
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 <liezhi.yang@windriver.com>
> ---
>  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.

Cheers,

Richard
Robert Yang July 2, 2019, 3:35 a.m.
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 <liezhi.yang@windriver.com>
>> ---
>>   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
> 
>