Sujet : Re: Centos stream of batpiss
De : invalid (at) *nospam* invalid.invalid (Richard Kettlewell)
Groupes : comp.os.linux.miscDate : 17. Jun 2024, 07:47:23
Autres entêtes
Organisation : terraraq NNTP server
Message-ID : <wwvle349ibo.fsf@LkoBDZeT.terraraq.uk>
References : 1 2 3 4 5 6 7 8 9
User-Agent : Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
not@telling.you.invalid (Computer Nerd Kev) writes:
Richard Kettlewell <invalid@invalid.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
Interesting. Were you able to track down the incompatibility any
further? Because it's always been my understanding that binaries
linked against older versions of libc.so.6 will continue to run
against newer versions, and a lot of work is done with symbol
versioning in glibc to ensure this.
They do; his issue is the other way around, i.e. trying to run newer
code on older Glibc.
>
It's pretty lucky that it worked before in that case. I thought Glibc
broke backwards compatibility very regularly and therefore the "line
in the sand" might mean an issue with Ubuntu 20's binaries running on
newer Glibc in Ubuntu 22, in spite of the usual efforts at forwards
compatibility.
It maintains backward compatibility well, in the sense that executables
and shared libraries built against an older version of Glibc will
generally run on newer versions. That’s what the OP was doing
‘before’. In the instance that didn’t work, they were attempting to do
the opposite.
-- https://www.greenend.org.uk/rjk/