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