diff options
author | Peter Seebach <peter.seebach@windriver.com> | 2014-08-14 13:03:36 -0500 |
---|---|---|
committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2014-08-15 18:19:52 +0100 |
commit | 513f72274460e54fd35dda5ef70fa42ba2b284f8 (patch) | |
tree | 783454fe2d7a48f46cc2fa2a583e91dc9ef07ac9 /meta/recipes-support | |
parent | 0ba6ab39f187ecd4261f08e768f365f461384a3a (diff) | |
download | openembedded-core-513f72274460e54fd35dda5ef70fa42ba2b284f8.tar.gz openembedded-core-513f72274460e54fd35dda5ef70fa42ba2b284f8.tar.bz2 openembedded-core-513f72274460e54fd35dda5ef70fa42ba2b284f8.zip |
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.
Signed-off-by: Peter Seebach <peter.seebach@windriver.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/recipes-support')
0 files changed, 0 insertions, 0 deletions