From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13873 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Revin Newsgroups: gmane.linux.lib.musl.general Subject: Re: ABI compatibility between versions Date: Tue, 26 Feb 2019 17:22:11 +0100 Message-ID: References: <20190226003353.GP23599@brightrain.aerifal.cx> <20190226095837.GC21289@port70.net> <20190226151137.GR23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="195054"; mail-complaints-to="usenet@blaine.gmane.org" Cc: musl@lists.openwall.com To: Rich Felker Original-X-From: musl-return-13889-gllmg-musl=m.gmane.org@lists.openwall.com Tue Feb 26 17:22:38 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 1gyfV7-000oYX-Mv for gllmg-musl@m.gmane.org; Tue, 26 Feb 2019 17:22:37 +0100 Original-Received: (qmail 3153 invoked by uid 550); 26 Feb 2019 16:22:35 -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 3132 invoked from network); 26 Feb 2019 16:22:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SBdoimj91KutH38iPH3NqJJmpgCFSxcSja/MA5v/Q3E=; b=CgvGKlAeBsylsxKYim1Q85PQU6gXQvGpfvDHr7Pb8xMw6fk2xQkxoHQhjPK5Q4TwyR afT0RwNYDLEpjHZHYW34HlfvlxPEP6Bax6HzVj13RWca/J/VjiIqlc2hYulUrEmCzEG7 rGytiwP9/lrGSriK7xTAj2uic5OwtQ4x0Pg9kVSrzSD6humSUJ1al7MRkFJrSH9er8Zw s8KtYRQ3n+2ooe6dvuP2Tu9fWWjCdT9B/W2ArfMeNU2H85Ibq7K2TFR16JKkjxvh/6sp RZcwYBVPoEuslyhhvqeOvav18mRRclixc/gPsYBaTEeij2ytCbCKCMfj5j9ud+xYpq0S 7gPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SBdoimj91KutH38iPH3NqJJmpgCFSxcSja/MA5v/Q3E=; b=E8GeO/ateU+bd+uo8HNu2tqPxJ09cmJM+Uf33nkpalXzYcNkNSyy+CfEvupFkuawu4 hx6AIlugah+M2skVPxF6nq0NIxt4yNQTD/yS4vVKB2ZGTJ3XxRE6CD+uT0/yAen8bpmQ yA5KCAZL/NM5HNH5Ak7aHQtlDnjKsQCJw1Z3VsgVnzrKrYZXv7Fpu4U3zmgcPW9U9O7h K6AdOe+3s0rR6jLDoVlUpQvK/98zSVrAbo61VDMKyj6YMxV0CMqnBIaIj7yRwG501lb2 b8hppzf9AMpCrYXTO1ZhHCvilgTNVDIwki9BBvH5ptZt1XJqU3iPovBYhyYOiEf6PK2S Qnrg== X-Gm-Message-State: AHQUAubSj/ise4g00h4cbjvK1qk/bkgROc3WHHQH3T9baaHEeuc7+Nyi mkNfJWoeMILS63uEQwFtEel5/SMMVW35gHeNTws= X-Google-Smtp-Source: AHgI3IbOqPTCJ1KYVRd9+TWxBNQW4CQbgse48v93cm7StrVSNjtOobHRNc/DkQH8Q3bW9ZC0gC1Hkx6I8ZT8RL1eifo= X-Received: by 2002:a5d:8404:: with SMTP id i4mr13328084ion.251.1551198142555; Tue, 26 Feb 2019 08:22:22 -0800 (PST) In-Reply-To: <20190226151137.GR23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13873 Archived-At: Thanks! I think that should be enough for Python problem On Tue, Feb 26, 2019 at 4:11 PM Rich Felker wrote: > > On Tue, Feb 26, 2019 at 12:28:31PM +0100, Alexander Revin wrote: > > Thanks for your answers. > > > > > 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). > > > > So it generally similar to glibc approach =E2=80=93 link against old mu= sl, > > which doesn't expose new symbols? > > This works but isn't necessarily needed. As long as your application > does not use any symbols that were introduced in a newer musl, it will > run with an older one, subject to any bugs the older one might have. > If configure is detecting and causing the program's build process to > link to new symbols in the newer musl, and you don't want to depend on > that, you can usually override the detections with configure variables > on the configure command line or in an explicit config.cache file, or > equivalent for other non-autoconf-based build systems. > > > I'm asking this because I'm investigating efforts required to bring > > Python native modules support to musl (at the present moment it's > > impossible to install any Python native module on musl system without > > recompiling) =E2=80=93 discussion is here: > > https://mail.python.org/archives/list/distutils-sig@python.org/thread/H= 3323AXRRLJAYOY2XZKS74IOUQMJUOYD/ > > > > On Tue, Feb 26, 2019 at 10:58 AM Szabolcs Nagy wrote: > > > > > > * 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: d= oes > > > > > musl guarantee in some way that executable/library compiled again= st > > > > > 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 someho= w > > > > > ensure the stability between releases? > > > > > > > > It guarantees that there is no ABI mismatch. That's not entirely th= e > > > > same as guaranteeing that it will work. If the application was rely= ing > > > > on a bug in an old version to function, or was poking at some > > > > accidentally-exposed libc internals not defined as a public interfa= ce, > > > > 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 versio= n > > > > of glibc the application was linked with. Such a system forces new > > > > application binaries that want to be able to run on systems with ol= d > > > > glibc to link against the old glibc, and thereby get the buggy > > > > behaviors even if they're running on a system without the bugs. Mys= elf > > > > 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).