From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13868 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: ABI compatibility between versions Date: Tue, 26 Feb 2019 10:58:38 +0100 Message-ID: <20190226095837.GC21289@port70.net> References: <20190226003353.GP23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="156898"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.10.1 (2018-07-13) Cc: Alexander Revin To: musl@lists.openwall.com Original-X-From: musl-return-13884-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 26 10:58:55 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gyZVm-000ehX-Hy for gllmg-musl@m.gmane.org; Tue, 26 Feb 2019 10:58:54 +0100 Original-Received: (qmail 3318 invoked by uid 550); 26 Feb 2019 09:58:50 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 3293 invoked from network); 26 Feb 2019 09:58:50 -0000 Mail-Followup-To: musl@lists.openwall.com, Alexander Revin Content-Disposition: inline In-Reply-To: <20190226003353.GP23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13868 Archived-At: * Rich Felker [2019-02-25 19:33:53 -0500]: > On Tue, Feb 26, 2019 at 12:18:06AM +0100, Alexander Revin wrote: > > Hi all, > > > > I know this have been briefly discussed here before, but still: does > > musl guarantee in some way that executable/library compiled against > > one musl version will work with another (for example, 1.18 and 1.21) > > ? > > > > I remember there were concerns against embedding versioning > > information in musl like glibc does, but is there a way to somehow > > ensure the stability between releases? > > It guarantees that there is no ABI mismatch. That's not entirely the > same as guaranteeing that it will work. If the application was relying > on a bug in an old version to function, or was poking at some > accidentally-exposed libc internals not defined as a public interface, > it's possible that updating libc.so will expose this bug in the > application. > > This is different from the glibc approach, which is to use symbol > versioning to attempt to retain "bug-compatibility" with the version > of glibc the application was linked with. Such a system forces new > application binaries that want to be able to run on systems with old > glibc to link against the old glibc, and thereby get the buggy > behaviors even if they're running on a system without the bugs. Myself > and most of the musl community I'm aware of consider this entirely > unreasonable, and that's why musl doesn't do it. i just want to add that glibc makes a distinction as well between public api contract and implementation internals and it does not aim to be compatible with anything that depends on internals (unless there is a strong reason to do so) so a binary may not work across glibc versions. other than the bug compatibility, a difference between the two approaches is that glibc may do certain abi breaking changes while keeping old binaries work, that musl cant do. but for this reason a binary compiled against a new version of glibc is unlikely to work with an older version (which is why anybody who wants to distribute a binary that works across different linux distros, compiles against a very old version of glibc, which of course means lots of old bugs) while for musl such breakage is much more rare (happens when a new symbol is introduced and the binary uses that).