Steps to reproduce: 1) bitbake meta-toolchain with gcc 4.6.0 2) bitbake meta-toolchain with gcc 4.5.1 in another project. If project 1 and 2 use the shared sstage-cache, then the build would fail: | Processing task-core-standalone-sdk-target-dbg... | error: Failed dependencies: | libgcc1 >= 4.6.0 is needed by eglibc-utils-2.13-r1+svnr14157.armv5te | error: LOOP: | error: removing libgcc-s-dev-4.5.1-r0.armv5te "Requires(hint): libc6-dev" from tsort relations. | error: removing libc6-dev-2.13-r1+svnr14157.armv5te "Requires(hint): libgcc-s-dev" from tsort relations. Workarounds: Remove sstate-elibc-* in sstate-cache
please provide some update on the bug since it's been a while from the last activity
Here was the information from Richard: 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 I think that we can mark it as WONTFIX