Deutsch English Français Italiano |
<666f6d49@news.ausics.net> View for Bookmarking (what is this?) Look up another Usenet article |
Message-ID: <666f6d49@news.ausics.net> From: not@telling.you.invalid (Computer Nerd Kev) Subject: Re: Centos stream of batpiss Newsgroups: comp.os.linux.misc References: <v04g5g$3hofl$1@paganini.bofh.team> <v05kel$uh9t$1@dont-email.me> <1cednanf4p_sOsf7nZ2dnZfqn_WdnZ2d@earthlink.com> <v3iuet$3i9vd$4@dont-email.me> <ToC8O.2$h4Ia.1@fx01.iad> <91I8O.16$raU6.4@fx16.iad> <v4ljsa$3s54t$2@dont-email.me> <wwvo780imvm.fsf@LkoBDZeT.terraraq.uk> User-Agent: tin/2.0.1-20111224 ("Achenvoir") (UNIX) (Linux/2.4.31 (i586)) NNTP-Posting-Host: news.ausics.net Date: 17 Jun 2024 08:55:06 +1000 Organization: Ausics - https://newsgroups.ausics.net Lines: 33 X-Complaints: abuse@ausics.net Path: ...!weretis.net!feeder9.news.weretis.net!news.bbs.nz!news.ausics.net!not-for-mail Bytes: 2483 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. -- __ __ #_ < |\| |< _#