From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 14113 invoked from network); 27 Jul 2020 20:57:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Jul 2020 20:57:29 -0000 Received: (qmail 31992 invoked by uid 550); 27 Jul 2020 20:57:27 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31974 invoked from network); 27 Jul 2020 20:57:26 -0000 X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dereferenced.org; s=default; t=1595883435; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=9u1f7jyvlnWF72us33R/vSnVX3tWZM2DyWYdG3GO/sQ=; b=psL5CE8EJyPOF8cCs5QSAOIJFU6ZYdOLAyobKwVxsBBLp56ZKYNPLgzjmNBdgE6hRZc7b0 bSl7D+GE7o1S4uSirW6Two2cH9XnynAaF45mJcUDiW+Snb4Z7ae4p7Uhx+A7kR9rztdNnJ RVV2SG7JzoxvNU+A/SAHvRp5exj+muk= From: Ariadne Conill To: musl@lists.openwall.com Date: Mon, 27 Jul 2020 14:57:10 -0600 Message-ID: <2983406.IqFZyr3sfq@localhost> In-Reply-To: <20200727160326.GN6949@brightrain.aerifal.cx> References: <1667998.jfqktxE8f0@localhost> <20200727160326.GN6949@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [musl] friendly errors for ABI mismatch Hello, On Monday, July 27, 2020 10:03:30 AM MDT Rich Felker wrote: > On Mon, Jul 27, 2020 at 09:27:28AM -0600, Ariadne Conill wrote: > > Hello, > > > > On 32-bit systems, musl 1.2 has a new ABI (due to time64). This results > > in > > programs built against musl 1.2 failing to run against musl 1.1. That > > part is fine, but you get an error message about being unable to relocate > > symbols, which is not really insightful if you don't know about the ABI > > break. > > > > glibc, on the other hand, has a minimum version specified in every binary, > > and prints an error message saying the glibc is too old if this situation > > is encountered. > > > > I think we should add this feature to musl, so that in the future if we > > have another ABI break, users will be given useful advice about how to > > fix it. Due to the relocation error message, a few Alpine contributors > > have been tripped up while trying to debug their work... > > What you're seeing here is just a special case of the general property > that, if you've linked to a version of libc (or any library) that has > a new symbol and attempt to run with an older version, you'll get a > missing symbol error. It's very intentional (see libc comparison and > "forward compatibility") that we don't encode "minimum version number" > required anywhere. If you attempt to run with a library that has all > the symbols, it will run, subject to any bugs in the library version > you have and any functionality that returns with failure because it's > not supported in the version you have, etc. > > There is no way to give a more high-level reason for the runtime link > failure like "your program needs time64 and you're running with an old > musl" because the code reporting the error *is the old musl* that's > not aware of whatever it is that the new binary is missing. Maybe you > have something else in mind that I don't fully understand, but > whatever it is it would only address future missing symbol errors, not > the ones you're seeing right now. Simply what I have in mind is having friendly errors in the future, obviously we cannot do it with time64. Ariadne