Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2020 15:54:00 -0500
From: "A. Wilcox" <>
Subject: Re: friendly errors for ABI mismatch

On 27/07/2020 11:03, Rich Felker wrote:
> 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.

I think the request here is to have a "minimum musl version" encoded in
the binary, so that the error would say "Sorry, this binary requires a
newer musl version than you have."

This is similar to the Win32 SUBSYSTEM property in PE.  "The specified
program requires a newer version of Windows."

The problem is that this would lead to the same issue that prevents musl
from defining a compiler macro with its number (#define __MUSL__
0x010201 or such) - those that backport patches and/or features to older
versions would necessarily be reporting a version number that is older
than the patch/feature.

Therefore, I don't see this working out for musl for the same reason.

The bug here is trying to run musl 1.2 programs on musl 1.1 at all; this
shouldn't even be possible.  I've certainly never hit this, even while
upgrading Adélie beta4 systems to RC1 on 32-bit computers.


A. Wilcox (awilfox)
Project Lead, Adélie Linux

Download attachment "signature.asc" of type "application/pgp-signature" (834 bytes)

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.