Sujet : Re: Centos stream of batpiss
De : not (at) *nospam* telling.you.invalid (Computer Nerd Kev)
Groupes : comp.os.linux.miscDate : 16. Jun 2024, 23:55:06
Autres entêtes
Organisation : Ausics - https://newsgroups.ausics.net
Message-ID : <666f6d49@news.ausics.net>
References : 1 2 3 4 5 6 7 8
User-Agent : tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586))
Richard Kettlewell <
invalid@invalid.invalid> wrote:
Lawrence D'Oliveiro <ldo@nz.invalid> writes:
On Fri, 07 Jun 2024 18:09:09 GMT, Charlie Gibbs wrote:
... and found a dependency on libc.so.6 which draws a line in the
sand between Ubuntu 20 and Ubuntu 22 (and their Debian equivalents).
I've always prided myself on creating binaries that will run on any
version of an OS, but this dream has been derailed. We've told our
Ubuntu 20 customers that if they want TLS 1.3 they have no choice but
to upgrade their OS to Ubuntu 22. Only then can we send them new
binaries. By the same token, our older binaries, which only support
TLS 1.1, will not run under Ubuntu 22 ...
>
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.
Musl libc is more forgiving with this, so switching to that might
be a solution provided no Glibc-specific features are being used
by the software or its users. It's packaged for Debian.
-- __ __#_ < |\| |< _#