Re: Can we trust to sstate-cache?

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2012-10-18 at 15:36 +0200, Marcin Juszkiewicz wrote:
> Today I bumped gcc-linaro from 4.7-r5 to 4.7-r6. First version was plain
> 2012.10 release while second one was tarball from bzr repository with
> huge set of ICE related fixes for AArch64 architecture.
> 
> To do fast clean build I removed TMPDIR and started new build of
> core-image-minimal target.
> 
> But then I noticed ugly thing:
> 
> 0: eglibc-2.16-r18+svnr20393 do_populate_sysroot_setscene (pid 30106)
> 1: eglibc-2.16-r18+svnr20393 do_package_setscene (pid 30107)
> 3: eglibc-initial-2.16-r18+svnr20393 do_package_setscene (pid 28921)
> 
> Why eglibc was taken from sstate-cache instead of being rebuilt (like it
> was with 'db')? This makes me sad as it shows that I cannot trust
> sstate-cache so each new build will take hours instead of minutes.
> 
> Or maybe I am wrong?

In order to try and stop people going entirely insane and to illustrate
the kind of controls that are possible, we have some default sstate
policy in:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/lib/oe/sstatesig.py

which basically stops the sstate sigs at the native/cross to target
boundary.

So in your specific case, it wouldn't rebuild eglibc even though you
changed gcc and this was expected. You could customise sstatesig.py to
change that (remove the isCross() bits).

Cheers,

Richard