[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 27 Jul 2020 23:16:56 +0200
From: Florian Weimer <fw@...eb.enyo.de>
To: Ariadne Conill <ariadne@...eferenced.org>
Cc: musl@...ts.openwall.com
Subject: Re: friendly errors for ABI mismatch
* Ariadne Conill:
> 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.
Are you concerned about static linking across musl versions, or the
dynamic run-time behavior?
There are limits what you can do without changing the entire
toolchain.
> 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.
Do you mean symbol versioning? It's a bit more flexible than that.
Symbol versions are only required if a symbol with that version is
actually used. And the symbol version does not have to be a number or
(in the GNU implementation) imply some sort of linear order.
Using symbol versioning has the advantage that the rest of the
toolchain already supports it.
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.
