From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7613 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Should we support (not use, support) symbol versioning? Date: Sat, 9 May 2015 21:03:59 -0400 Message-ID: <20150510010359.GA8002@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1431219869 22930 80.91.229.3 (10 May 2015 01:04:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 May 2015 01:04:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-7626-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 10 03:04:24 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1YrFfH-0001Ax-Cj for gllmg-musl@m.gmane.org; Sun, 10 May 2015 03:04:19 +0200 Original-Received: (qmail 20267 invoked by uid 550); 10 May 2015 01:04:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 20232 invoked from network); 10 May 2015 01:04:12 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:7613 Archived-At: 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