Can we trust to sstate-cache?
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?
Quoted 13 lines · Marcin Juszkiewicz
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+svnr20393do_package_setscene(pid 30107) 3: eglibc-initial-2.16-r18+svnr20393do_package_setscene(pid 28921)
Quoted 5 lines
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?
Did the signatures for eglibc change after making your gcc-linaro change? You can run bitbake -S before and after and see which ones have new stamps. Then you can start using bitbake-diffsigs to back track (or presumably if nothing changed add a proper dependency)
-M
Quoted 13 lines · Marcin Juszkiewicz
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+svnr20393do_package_setscene(pid 30107) 3: eglibc-initial-2.16-r18+svnr20393do_package_setscene(pid 28921)
Quoted 5 lines
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