Hi,
Just realized this change was never merged into master, so see this as a friendly reminder about this change-set (might have been lost in the flood of changes in this time-frame). Not the most common use case I guess, but would be good to finally get rid of the problem. If you have any concerns about the change, please let me know. The solution was briefly discussed with Richard on irc a couple of month ago, but if someone thinks this should be solved in some other way, please initiate a discussion :) BR Petter 2017-05-15 06:17 skrev Petter Mabäcker: > Due to the problem fixed in > '56c677a multilib: Move redefinition of STAGING_DIR_KERNEL' > STAGING_KERNEL_DIR must be redefined for lib32 in multilib.bbclass. > However this redefinition expanded STAGING_KERNEL_DIR to an absolute > path. This unconsciously added the TMPDIR path in the sstate object, > causing packages depended on STAGING_KERNEL_DIR being rebuild if the > TMPDIR was changed. > > Solve this by forcing the unexpanded TMPDIR variable to remain in the > beginning of STAGING_DIR_KERNEL (as default). Since TMPDIR is included in > BB_HASHBASE_WHITELIST, the sstate object will not be depended on the > expanded path anymore. > > Signed-off-by: Petter Mabäcker <[email protected]> > --- > meta/classes/multilib.bbclass | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/meta/classes/multilib.bbclass b/meta/classes/multilib.bbclass > index ab04597..816f54e 100644 > --- a/meta/classes/multilib.bbclass > +++ b/meta/classes/multilib.bbclass > @@ -4,7 +4,9 @@ python multilib_virtclass_handler () { > if cls != "multilib" or not variant: > return > > - e.data.setVar('STAGING_KERNEL_DIR', e.data.getVar('STAGING_KERNEL_DIR')) > + localdata = bb.data.createCopy(e.data) > + localdata.delVar('TMPDIR') > + e.data.setVar('STAGING_KERNEL_DIR', localdata.getVar('STAGING_KERNEL_DIR')) > > # There should only be one kernel in multilib configs > # We also skip multilib setup for module packages. > -- > 1.9.1
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
