Updating a system, glibc failed to update. Its been stuck at an older version due to looking for stubs32.h on a 64bit system. Something else messed up maybe with hardened. I notice a m32 during compile, which I believe should be m64 on a 64bit non-multilib system. None the less, glibc-2.25 failed to merge, but it continued on and merged in coreutils binary that was built against glibc-2.25. Essentially crippling the system, and making it very difficult to fix. Most core commands generate the following mv: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by mv) cp: /lib64/libc.so.6: version `GLIBC_2.25' not found (required by cp) This really should never happen. No way coreutils should have merged in given it was built against a glibc version that failed to merge. The entire dep chain should have been skipped. I believe this problem exists because glibc is not a direct dependency of coreutils. Which is pretty crazy given the above. Maybe adding glibc to coreutils would prevent such from happening. I frequently make and merge binaries. Usually when something a binary was built against fails to merge, the rest is dropped. That clearly did not happen in this case and it really should have. There are not many packages more important than coreutils and glibc....
Portage team: can you comment on the expected binpkg behavior here?
(In reply to William L. Thomson Jr. from comment #0) > This really should never happen. No way coreutils should have merged in > given it was built against a glibc version that failed to merge. Unfortunately, we don't have a way to track the glibc version that a particular package was built against. Slot operators and subslots don't quite fit, since it's not appropriate to rebuild all packages after a glibc upgrade (because the libc.so.6 soname does no change).
(In reply to Zac Medico from comment #2) > (In reply to William L. Thomson Jr. from comment #0) > > This really should never happen. No way coreutils should have merged in > > given it was built against a glibc version that failed to merge. > > Unfortunately, we don't have a way to track the glibc version that a > particular package was built against. Slot operators and subslots don't > quite fit, since it's not appropriate to rebuild all packages after a glibc > upgrade (because the libc.so.6 soname does no change). What about something simple? Not sure if this would suffice, but seems to work. $ grep -i glibc_2.25 /bin/mv Binary file /bin/mv matches If you specify a version other than the one it was built again you get no output. Not sure if that could be used for like coreutils. Not practical for all packages, but the core base system packages, or at least core utils. How that would fit into a dep calculation, no clue. That is likely something done more as a check in a phase, prepare, etc. Maybe something custom for coreutils given its dependence on glibc, and damage to system when coreutils is broken. Your limited to like busybox.
*** This bug has been marked as a duplicate of bug 753500 ***
