mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Florian Weimer <fw@deneb.enyo.de>
To: Rich Felker <dalias@libc.org>
Cc: musl@lists.openwall.com
Subject: Re: [musl] friendly errors for ABI mismatch
Date: Tue, 28 Jul 2020 10:40:35 +0200	[thread overview]
Message-ID: <871rkwuj5o.fsf@mid.deneb.enyo.de> (raw)
In-Reply-To: <20200727215001.GO6949@brightrain.aerifal.cx> (Rich Felker's message of "Mon, 27 Jul 2020 17:50:01 -0400")

* Rich Felker:

> Symbol versioning, if used, changes this somewhat by binding to a
> particular version string (which by convention usually contains a
> library name too) *if* the library used to resolve it at runtime has
> versioning, but for very good reasons we have not used and do not want
> to use symbol versioning. (In short, like here it's an "approximate
> solution" for most things people want to use it for, doesn't actually
> achieve those things precisely, messes other things up in the process,
> and has really really bad tooling support.)

I think you should look at this from a different angle.  You could use
it just to produce an error message in case there is an ABI change,
but not for backwards compatibility with old binaries or enabling
otherwise ABI-incompatible changes without rebuilding the world.

With this approach, all symbols would have a single, default version.
New releases do not add new symbol version strings in general, except
when there is something like time64_t, in which the default (and only
version) for those symbols changes.  Over time, you will end up with a
few symbol versions, but at a much slower pace than what glibc does.

  reply	other threads:[~2020-07-28  8:40 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-07-27 15:27 Ariadne Conill
2020-07-27 16:03 ` Rich Felker
2020-07-27 20:54   ` A. Wilcox
2020-07-27 20:57   ` Ariadne Conill
2020-07-27 21:50     ` Rich Felker
2020-07-28  8:40       ` Florian Weimer [this message]
2020-07-29  1:16         ` Rich Felker
2020-07-27 21:16 ` Florian Weimer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=871rkwuj5o.fsf@mid.deneb.enyo.de \
    --to=fw@deneb.enyo.de \
    --cc=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).