On Sun, 2019-12-22 at 12:08 +0000, Richard Purdie wrote: > On Sun, 2019-12-22 at 10:54 +0000, Richard Purdie wrote: > > I did a little digging on the weird hash equiv failure. I've > > attached two logs, one is the simplified console output, the other > > is the reams of debug.
I did a bit more thinking about this. These hashes represent m4-native. We do have a problem that a given input hash for m4-native can represent two different output states depending on the architecture it was built on. For the same input hash, the output hash of these two things will never match. Nor will there ever be present sstate for them to trigger the report equiv mechanism. At query time in a clean build, the hashserver cannot know which of the two output hashes it needs to return the value for. I can think of two possible options: a) When we report after running a task, we check if that input hash already has a value and then reuse it for the output hash mapping. b) We start adding some kind of suffix to the reported hashes for native output which is used within the hash equiv server but not sstate. I freely admit this needs much more thought... Cheers, Richard -- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
