Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 636914 - sys-apps/coreutils binary merged built against glibc-2.25
Summary: sys-apps/coreutils binary merged built against glibc-2.25
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: .tbz2 support (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-11-08 20:23 UTC by William L. Thomson Jr.
Modified: 2017-11-12 16:30 UTC (History)
2 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description William L. Thomson Jr. 2017-11-08 20:23:47 UTC
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....
Comment 1 Mike Gilbert gentoo-dev 2017-11-12 04:03:30 UTC
Portage team: can you comment on the expected binpkg behavior here?
Comment 2 Zac Medico gentoo-dev 2017-11-12 04:52:38 UTC
(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).
Comment 3 William L. Thomson Jr. 2017-11-12 16:30:00 UTC
(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.