bug 1169 eglibc doesn't depend on gcc version correctly

Hi experts,

There is a bug 1169: eglibc doesn't depend on gcc version correctly,

The produce steps are:

1) In the first build dir(e.g, build_1), edit conf/local.conf:
SSTATE_DIR = /path/to/share_sstate

   $ bitbake meta-toolchain

2) In the second build dir(e.g, build_2), edit local.conf:
SSTATE_DIR = /path/to/share_sstate SDKGCCVERSION="4.5.1"
GCCVERSION="4.5.1"

   $ bitbake meta-toolchain

Then we will notice the error:
| error: Failed dependencies:
| libgcc1 >= 4.6.0 is needed by eglibc-utils-2.13-r1+svnr14157.armv5te

The reason is a little complicated:
As we can see that eglibc's RDPENDS should have 'libgcc', but eglibc's DEPENDS(not RDEPENDS) can't have libgcc, otherwise there would be loop dependencies(since libgcc already DEPENDS on eglibc), this causes eglibc.do_package can't detect that the version of libgcc or gcc has been changed from 4.6 to 4.5.1, so it would mirror the sstate-eglibc-xxx_package.tgz(which is stored by gcc 4.6) from the SSTATE_DIR, and then it would do_package_write_rpm from the data of sstate-eglibc-xxx_package.tgz, but the objdump can find that the binary file depends on the special version of libgcc, and it would write the data( libgcc1 >= 4.6.0) to eglibc.spec, but the current version of libgcc is 4.5.1, so there would be dependencies error when do_rootfs.

I don't know how to fix this, maybe we should not mirror the tarball of sstate-xxx_package.tgz(which is mirrored according to the DEPENDS) from the SSTATE_DIR, but only mirror the tarball of sstate-xxx_deploy-rpm.tgz(which is mirrored according to the RDEPENDS, the RDEPENDS is what the binary rpm package really cares), the similar to ipk and deb.

Thanks

Robert

The sstate checksum of the sstate-eglibc-xxx_package.tgz package should have changed when the gcc version changed, such that it would repackage (based on updated data). I think the problem is that in the sstate code, we've assumed the toolchain is special and can change:

BB_HASHTASK_WHITELIST ?= "(.*-cross$|.*-native$|.*-cross-initial$|.*-cross-intermediate$|^virtual:native:.*|^virtual:nativesdk:.*)"

and this may be a sign we should reconsider this. Alternatively we could hiighlight we simply don't support gcc version going backwards...

Cheers,

Richard