1169 2011-06-15 18:46:02 +0000 eglibc doesn't depend on gcc version correctly 2011-12-20 18:04:28 +0000 1 1 7 Build System, Metadata & Runtime OE-Core core 0.9 x86 Multiple RESOLVED WONTFIX post 1.1 Medium normal 1.2 1 liezhi.yang liezhi.yang jessica.zhang liang.li2 liangliang.wang meta.mr.watcher meta.watcher sgw yi.zhao --- --- --- oldest_to_newest 14299 0 liezhi.yang 2011-06-15 18:46:02 +0000 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 17760 1 jessica.zhang 2011-12-20 11:36:23 +0000 please provide some update on the bug since it's been a while from the last activity 17771 2 liezhi.yang 2011-12-20 18:04:28 +0000 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