[poky] a new problem with sstate

[Tian, Kevin]

When looking into the problem why some prebuilts can't be reused, I've struggled with
another issue these days. It's more severe because the 2nd build can't even succeed
when prebuilt is used.

The failure happened randomly on eglibc, eglibc-initial, and gcc-runtime. The error log
shows that either gcc libraries or eglibc headers are not correctly installed when building
those recipes. This first led me to think about potential dependency problem among 
those recipes. However this only happens when prebuilt is used. A fresh build just 
succeeds.

Finally it turns out from two factors:

	o sstate.bbclass has special handling about -initial and -intermediate recipes. If 
a complete (e.g. gcc-cross or eglibc) setscene function has been invoked already, 
installation for those special sstate packages is skipped, while still marked as 
accelerate-able

	o eglibc and gcc-runtime happen to have new changes between two builds and
thus require rebuild

Then the problem comes:
	- eglibc depends on gcc-cross-intermediate
	- gcc-cross-intermediate is marked as accelerated but no sstate installation actually
happens, which is simply a nop
	- gcc-cross is assumed to provide required bits, which depends on eglibc instead
and thus hasn't been started

Then eglibc compilation fails because libgcc is missing

So the key problem is about libc/gcc bootstrap process. We have plan in 1.0 to improve
bootstrap process, by having initial/intermediate bits installed to its own locations, which
should solve this problem too. However before that feature is ready, we still need
some workaround to have current sstate/prebuilt really usable, since it's very likely to
have eglibc/gcc recipe revised occasionally.

I have three options in mind:

	a) disable special handling in sstate.bbclass for -initial and -intermediate recipes, i.e.
always have all sstate packages installed. I think it's perhaps OK, but it may increase 
build time a bit and I may overlook something behind

	b) have the whole libc/gcc bootstrap process as a bundle when handling the sstate
task, i.e. any one stage failing to reuse prebuilt results in all relevant recipes excluding
from the acceleration list. However bitbake now executes tasks in  separate threads.
So I'm not sure how easily that cross-recipe info may be retrieved there. Perhaps some
database and postfunc is required

	c) always touch all gcc/libc recipes if any of them is changed to ensure all recipes
rebuilt from scratch. This however increases build time a lot and not convenient

I personally prefer to a), but need more experiments to ensure it working correctly,
but would like to get your comments too. :-)

Thanks
Kevin