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.

-- 
__          __
#_ < |\| |< _#