From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Should we support (not use, support) symbol versioning?
Date: Sat, 9 May 2015 21:03:59 -0400 [thread overview]
Message-ID: <20150510010359.GA8002@brightrain.aerifal.cx> (raw)
At present musl's dynamic linker does not support symbol versioning.
It always resolved all symbol lookups to the same (usually this means
latest) version ld would resolve them to, and ignores all
compatibility symbols. This is breaking a new hack in libgcc_s.so
that's going to affect us with new GCC versions.
We can't just outright honor versions like glibc does because of ABI
compat: we want glibc-linked apps/libs, which are referencing all
sorts of versioned symbols from glibc, to have those references
satisfied by the unversioned symbols in musl.
What we could possibly do, however, is honor the version requested
whenever the library being searched has version information. This
would allow third-party libraries that want to use versioning to do so
while also allowing unversioned libraries to satisfy any program or
library using them (and work correctly as long as it's using the
latest version API, just like now). However I'm mildly concerned that
symbol version tables could get introduced into libraries that don't
want them (including into libc.so) which would then horribly break
things, e.g. if any of libgcc.a's symbols were versioned (in principle
this should not happen, because they're all supposed to be hidden, but
I'm not really happy relying on that).
If that doesn't seem viable, there are some hacks we could do to fix
libgcc_s.so, or we could try to get gcc to build it without the
version hacks on musl targets, but I don't know how that would go.
None of this changes the reasons why symbol versioning is a horrible
mistake/misdesign and should not be used for anything; it's just a
matter of trying to keep things from breaking where others are using
it...
Rich
next reply other threads:[~2015-05-10 1:03 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-05-10 1:03 Rich Felker [this message]
2015-05-10 2:18 ` Rich Felker
2015-05-10 4:53 ` Рысь
2015-05-10 11:51 ` u-wsnj
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=20150510010359.GA8002@brightrain.aerifal.cx \
--to=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).