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:21:50 +0100 |
commit | cb1ab746ddc4c53f6825f3a9598b21bc5bdb7ef5 (patch) | |
tree | ada85d5bd4611ef11afd4aad0ee15599214c7eee /meta/recipes-support | |
parent | c0a071e16ec04f485f06eece5b807e5afbe1c1f1 (diff) | |
download | poky-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-support')
0 files changed, 0 insertions, 0 deletions