summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/opkg
diff options
context:
space:
mode:
authorPeter Seebach <peter.seebach@windriver.com>2014-08-14 13:03:36 -0500
committerRichard Purdie <richard.purdie@linuxfoundation.org>2014-08-15 18:21:50 +0100
commitcb1ab746ddc4c53f6825f3a9598b21bc5bdb7ef5 (patch)
treeada85d5bd4611ef11afd4aad0ee15599214c7eee /meta/recipes-devtools/opkg
parentc0a071e16ec04f485f06eece5b807e5afbe1c1f1 (diff)
downloadpoky-cb1ab746ddc4c53f6825f3a9598b21bc5bdb7ef5.tar.gz
multilib_global.bbclass: PREFERRED_PROVIDERS for multilibs
The code in base.bbclass to spread PREFERRED_PROVIDERS values to multilibs doesn't work for things which rely on TARGET_PREFIX, such as virtual/${TARGET_PREFIX}gcc. This is because the expansion of TARGET_PREFIX produces the wrong value if executed prior to the assignment of TARGET_VENDOR_virtclass-multilib-libxx, which will always happen since that assignment doesn't happen until recipe parsing, but the PREFERRED_PROVIDERS expansion is happening around ConfigParsed. To solve this, we make a couple of changes. First, the creation of the TARGET_VENDOR override values is moved into a new ConfigParsed event handler in multilib_global. Second, the preferred_ml_updates() function's code is moved into that function too. It seems safe to assume that PREFERRED_PROVIDER values only need to be spread to other multilibs when multilibs are in use. I don't think this directly affects any use cases that don't involve third-party or alternative toolchains. (From OE-Core rev: 513f72274460e54fd35dda5ef70fa42ba2b284f8) Signed-off-by: Peter Seebach <peter.seebach@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-devtools/opkg')
0 files changed, 0 insertions, 0 deletions