[poky] update about sstate relocation issue

[Tian, Kevin]

Recently we found some relocation issues when use sstate packages in a new
build environment where the original staging path generating those sstate
packages is missing. This is a typical scenario on using sstate, e.g. by delivering
prebuilt sstate packages to your customers, or create a mirror in a group dev
environment. 

Now I want to say this issue has been basically solved with recent fixes on:

	perl-native,	bison-native, flex-native: encode original staging path in binary
	perl, binutils: use its own ${CC} without --sysroot option
	gcc: c++ include path is not relative to --sysroot option
	kernel tool: use ${KERNEL_CC} instead of ${CC}

I verified below scenario with above fixes:

	a) build a sato image in BUILD1
	b) copy below sstate packages from BUILD1 to SSTATE_NATIVE:
		*i686*
		*libtool-cross*
		*eglibc*
		*linux-libc-headers*
		*gcc-runtime"
	c) rename BUILD1 to BUILD1.bak
	d) create a new BUILD2, with SSTATE_MIRROR pointing to SSTATE_NATIVE dir
	e) build poky image in BUILD2

Because the relocation issues are normally related to native packages, so above
test ensures the 2nd BUILD2 reusing all the native packages generated from BUILD1,
while building all target recipes from scratch. BUILD1 is renamed to ensure the
false reference is caught.

All of above have been in the master. So I think it's time for a wider test on sstate now. :-)

Thanks
Kevin