[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2020 15:54:00 -0500
From: "A. Wilcox" <awilfox@...lielinux.org>
To: musl@...ts.openwall.com
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.
Best,
--arw
--
A. Wilcox (awilfox)
Project Lead, Adélie Linux
https://www.adelielinux.org
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.
