summaryrefslogtreecommitdiffstats
diff options
context:
space:
mode:
authorRichard Purdie <richard.purdie@linuxfoundation.org>2019-06-25 15:21:45 +0100
committerRichard Purdie <richard.purdie@linuxfoundation.org>2019-06-27 12:20:36 +0100
commit16cd4ae3d57b44a4ac1e3a8ff989d1d00df819da (patch)
treee49d1f78ccb9dcf6c70dcd2b425c26bd958475b6
parenta478ad4c2d062e8b50fb7dc1fc88a728fc26ace6 (diff)
downloadpoky-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>
-rw-r--r--meta/classes/multilib_global.bbclass3
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
204addhandler multilib_virtclass_handler_global 204addhandler multilib_virtclass_handler_global
205multilib_virtclass_handler_global[eventmask] = "bb.event.RecipeParsed" 205multilib_virtclass_handler_global[eventmask] = "bb.event.RecipeTaskPreProcess"
206