diff options
| author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2019-06-25 15:21:45 +0100 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2019-06-27 12:20:36 +0100 |
| commit | 16cd4ae3d57b44a4ac1e3a8ff989d1d00df819da (patch) | |
| tree | e49d1f78ccb9dcf6c70dcd2b425c26bd958475b6 /meta/classes/multilib_global.bbclass | |
| parent | a478ad4c2d062e8b50fb7dc1fc88a728fc26ace6 (diff) | |
| download | poky-16cd4ae3d57b44a4ac1e3a8ff989d1d00df819da.tar.gz | |
multilib_global: Fix multilib rebuild issue
Building lttng-modules for a "lib32" multilib, then changing to a "lib64"
multilib with "lib32" removed doesn't rebuild lttng-modules.
This is due to the multilib pieces in RPROVIDES being added after RecipeParsed
which is after the signatures are generated.
Changing this to RecipeTaskPreProcess allows the multilib components to be
accounted for correctly in the task hashes.
This addresses failures on the autobuilder seen in lib64-core-image-sato-sdk
builds where lttng-modules was being reused from qemux86 world build's lib32
version.
(From OE-Core rev: a8dc13d4e4e34b061be5c2dd71f26cc0ad92a72e)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
Diffstat (limited to 'meta/classes/multilib_global.bbclass')
| -rw-r--r-- | meta/classes/multilib_global.bbclass | 3 |
1 files changed, 1 insertions, 2 deletions
diff --git a/meta/classes/multilib_global.bbclass b/meta/classes/multilib_global.bbclass index 19ce1a5091..11ac5b0457 100644 --- a/meta/classes/multilib_global.bbclass +++ b/meta/classes/multilib_global.bbclass | |||
| @@ -202,5 +202,4 @@ python multilib_virtclass_handler_global () { | |||
| 202 | } | 202 | } |
| 203 | 203 | ||
| 204 | addhandler multilib_virtclass_handler_global | 204 | addhandler multilib_virtclass_handler_global |
| 205 | multilib_virtclass_handler_global[eventmask] = "bb.event.RecipeParsed" | 205 | multilib_virtclass_handler_global[eventmask] = "bb.event.RecipeTaskPreProcess" |
| 206 | |||