Since a binary package will not work unless the required versions of glibc magic compat symbols are available, it would be nice to track these as dynamic symbol version dependencies in a way similar to how we already track soname dependencies.
*** Bug 802303 has been marked as a duplicate of this bug. ***
Is glibc's symbol versioning special here? Any symbol addition into the library should have similar semantics.
*** Bug 636914 has been marked as a duplicate of this bug. ***
A hack would be to just force implicit >= deps on glibc at least (where elibc_glibc) as glibc is the main one that's fatal here for new versions.
(In reply to Sam James from comment #4) > A hack would be to just force implicit >= deps on glibc at least (where > elibc_glibc) as glibc is the main one that's fatal here for new versions. We have a hack in emerge that makes it try to install virtual/os-headers and virtual/libc at the earliest opportunity.
(In reply to Zac Medico from comment #5) > (In reply to Sam James from comment #4) > > A hack would be to just force implicit >= deps on glibc at least (where > > elibc_glibc) as glibc is the main one that's fatal here for new versions. > > We have a hack in emerge that makes it try to install virtual/os-headers and > virtual/libc at the earliest opportunity. If I understand correctly, that solves the ordering problem, but wouldn't solve the problem of a stable system trying to use binary packages that need unstable glibc.
(In reply to Sam James from comment #4) > A hack would be to just force implicit >= deps on glibc at least (where > elibc_glibc) as glibc is the main one that's fatal here for new versions. Let's cover this in (the newly-filed) bug 913628.
*** Bug 913956 has been marked as a duplicate of this bug. ***
ftr bug 913628 is the thing being actively worked on
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=af550b8b5cb91f27b26d6800c3b4cdd2d86a46e6 commit af550b8b5cb91f27b26d6800c3b4cdd2d86a46e6 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-09-04 15:38:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-10 22:01:48 +0000 ebuild: inject implicit libc RDEPEND Inject >=${LIBC_PROVIDER}-${VERSION_OF_LIBC_PROVIDER} into RDEPEND. We already try to upgrade the virtual/libc provider and its deps aggressively but that's not so helpful if there's a binpkg for, say, one of its deps available built against a newer glibc - which ends up breaking the system because our glibc isn't new enough (symbol versioning). This is a long-standing problem for binpkg users and one of the last showstoppers for being able to use them reliably. Note that this applies to source installs too, although it matters less there; it'll make downgrading libc a bit harder for people who want to do that, but users are already prevented from doing that (pkg_* check) for glibc, and I don't really see it as a bad thing to effectively propagate this to other libcs. To fully solve the problem, we should arguably do at least one of the following: 1) Implicit >= on anything (not just libc) which installs ELF (at least a PROVIDES); 2) Implement the suggestion in bug #753500 based on analysis of used versioned symbols (*). But libc is really the critical one and the one where things explode pretty badly, especially combined with us trying to Do The Right Thing for non-binpkg cases (aggressively upgrading libc before anything else). The other cases don't matter so much as they get upgraded later and by that point, the library is usually done. (It's not really clear if downgrading musl works and even if it is supported, I'm not really sure it's a supported case at all, so I'm not bothering to carve out an exception here. It'd make this far less elegant and I don't see any benefit to doing so.) (*) util-linux is one of the examples I have in mind here as justification for either point. Bug: https://bugs.gentoo.org/753500 Bug: https://bugs.gentoo.org/913628 Signed-off-by: Sam James <sam@gentoo.org> lib/_emerge/actions.py | 7 +- lib/_emerge/depgraph.py | 22 + lib/portage/dep/__init__.py | 23 +- lib/portage/dep/libc.py | 83 ++++ lib/portage/dep/meson.build | 1 + lib/portage/package/ebuild/doebuild.py | 56 ++- lib/portage/tests/dep/meson.build | 1 + lib/portage/tests/dep/test_libc.py | 81 ++++ lib/portage/tests/emerge/meson.build | 1 + lib/portage/tests/emerge/test_actions.py | 23 +- lib/portage/tests/emerge/test_libc_dep_inject.py | 551 +++++++++++++++++++++++ 11 files changed, 831 insertions(+), 18 deletions(-)
*** Bug 931149 has been marked as a duplicate of this bug. ***
Doing this reliably as a general concept could imply scanning packages for @GLIBC_2.39 in symbols, deduping and sorting the results, and taking the highest version to inject as a >= To extend this to other packages, packages would probably want to somehow define their symbol pattern. So e.g. "GLIBC_([0-9.]+)" would be an attribute of the sys-libs/glibc package, instead of being a portage quirk. Not all packages are accommodating enough to provide this info... :( It doesn't seem scanelf can do this, though it is simple by parsing the output of `nm`. From the scanelf TODO: we don't handle versioned symbols well. take an ELF with debugging and do: scanelf -s '' elf notice that glibc symbols generally have version info. then search for that: scanelf -s foo@@ver elf no hits as all of our symbol comparisons ignore the versioning info.
It seems like something that maybe belongs as a future EAPI?
