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.3 required=5.0 tests=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 11708 invoked from network); 27 Jul 2020 16:03:53 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 27 Jul 2020 16:03:53 -0000 Received: (qmail 9815 invoked by uid 550); 27 Jul 2020 16:03:48 -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 9789 invoked from network); 27 Jul 2020 16:03:47 -0000 Date: Mon, 27 Jul 2020 12:03:30 -0400 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200727160326.GN6949@brightrain.aerifal.cx> References: <1667998.jfqktxE8f0@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1667998.jfqktxE8f0@localhost> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] friendly errors for ABI mismatch 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. In regards to Alpine, I get this kind of error *all the time* with all sorts of non-libc libraries while using edge. It's a consequence of the package management system not encoding a dependency on the version of the library package it was built against, which can be a good thing (see "forwards compatibility" above -- it avoids the need to unnecessarily upgrade a library package just because the system the dependent package was built on happened to have a newer version installed) but inherently leads to this sort of issue. Even if we could "fix" it in libc somehow, it would still happen all over the place with other libraries. Rich