Bug 3874

Summary: Overrides are evaluated for primary and multilib configuration, causing potential conflicts
Product: [Build System, Metadata & Runtime] OE-Core Reporter: Mark Hatle <mark.hatle>
Component: coreAssignee: Richard Purdie <richard.purdie>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: Medium+ CC: meta.mr.watcher, meta.watcher
Version: 1.4   
Target Milestone: 1.4 M4   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---

Description Mark Hatle 2013-02-11 16:35:03 UTC 
Reproducer:

cd meta/recipes-devtools/valgrind
touch valgrind-3.8.1/powerpc.patch
touch valgrind-3.8.1/powerpc64.patch

edit valgrind_3.8.1.bb

+SRC_URI_append_powerpc = " file://powerpc.patch"
+SRC_URI_append_powerpc64 = " file://powerpc64.patch"


cd meta/conf/machine
cp qemuppc.conf qemuppc64.conf

edit qemuppc64.conf:

-require conf/machine/include/tune-ppc603e.inc
+require conf/machine/include/tune-ppce5500.inc

(Note, this will not result in functional machine, but it's enough to reproduce the problem!)

modify your conf/local.conf

MACHINE = "qemuppc64.conf"

require conf/multilib.conf
MULTILIBS = "multilib:lib64"
DEFAULTTUNE_virtclass-multilib-lib64 = "ppc64e5500"


To see the problem:
bitbake -e valgrind | grep "^SRC_URI="


SRC_URI="http://www.valgrind.org/downloads/valgrind-3.8.1.tar.bz2          file://fix_issue_caused_by_ccache.patch            file://fix_unsupporting_kernel_3.patch            file://fixed-perl-path.patch            file://Added-support-for-PPC-instructions-mfatbu-mfatbl.patch            file://configure-with-newer-glibc.patch            file://powerpc.patch"

(that is correct)


bitbake -e lib64-valgrind | grep "^SRC_URI="

SRC_URI="http://www.valgrind.org/downloads/valgrind-3.8.1.tar.bz2          file://fix_issue_caused_by_ccache.patch            file://fix_unsupporting_kernel_3.patch            file://fixed-perl-path.patch            file://Added-support-for-PPC-instructions-mfatbu-mfatbl.patch            file://configure-with-newer-glibc.patch            file://powerpc.patch file://powerpc64.patch"

(that is incorrect, both powerpc and powerpc64 are listed!)

The 'OVERRIDES=' values for both are correct...  What appears to be happening is SRC_URI is evaluated twice.
Comment 1 Mark Hatle 2013-02-11 19:59:33 UTC 
After some investigation.  It appears that the problem is related to the order in which bitbake processes various anonymous python chunks, specifically in:

bitbake/lib/bb/parse/ast.py:

def finalize(fn, d, variant = None):
    all_handlers = {}
    for var in d.getVar('__BBHANDLERS') or []:
...
    bb.event.fire(bb.event.RecipePreFinalise(fn), d)

    bb.data.expandKeys(d)
    bb.data.update_data(d)
    code = []
    for funcname in d.getVar("__BBANONFUNCS") or []:
        code.append("%s(d)" % funcname)
    bb.utils.better_exec("\n".join(code), {"d": d})
    bb.data.update_data(d)
...

The first update_data sets the values (and appends) using the default tune, while the second sets the values based on the updated OVERRIDES settings from the anonfuncs.
Comment 2 Mark Hatle 2013-02-11 20:03:41 UTC 
Possible workaround (fix?) from Richard Purdie:


diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass
index 5454b4c..d52f721 100644
--- a/meta/classes/multilib.bbclass
+++ b/meta/classes/multilib.bbclass
@@ -51,6 +51,11 @@ python multilib_virtclass_handler () {
     e.data.setVar("PN", variant + "-" + e.data.getVar("PN", False))
     e.data.setVar("SHLIBSDIR_virtclass-multilib-" + variant ,e.data.getVar("SHL
     e.data.setVar("OVERRIDES", e.data.getVar("OVERRIDES", False) + override)
+
+    # Workaround for issue in YP Bugzilla #3874
+    newtune = e.data.getVar("DEFAULTTUNE_" + "virtclass-multilib-" + variant)
+    if newtune:
+        e.data.setVar("DEFAULTTUNE", newtune)
 }
 
 addhandler multilib_virtclass_handler
Comment 3 Richard Purdie 2013-02-11 22:43:12 UTC 
The issue is that OVERRIDES has virtclass-multilib-xxxx added to it, this eventually changed DEFAULTTUNE which then changes TRANSLATED_TARGET_ARCH which is in OVERRIDES meaning we then need to reevaulate the overides and the TTA gets applied twice since once you apply an override, it doesn't get undone.

Expanding DEFAULTTUNE to the correct value in advance avoids the issue and means only the correct overrides get applied.