From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8395 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Adjustments to roadmap Date: Fri, 28 Aug 2015 13:18:18 -0400 Message-ID: <20150828171818.GC7833@brightrain.aerifal.cx> References: <20150828024347.GA7624@brightrain.aerifal.cx> <20150828072422.GE11263@example.net> <20150828183932.0f03a8d5@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1440782318 20253 80.91.229.3 (28 Aug 2015 17:18:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 17:18:38 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8407-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 28 19:18:38 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 1ZVNIP-0002K3-3L for gllmg-musl@m.gmane.org; Fri, 28 Aug 2015 19:18:33 +0200 Original-Received: (qmail 1790 invoked by uid 550); 28 Aug 2015 17:18:31 -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 1761 invoked from network); 28 Aug 2015 17:18:30 -0000 Content-Disposition: inline In-Reply-To: <20150828183932.0f03a8d5@r2lynx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8395 Archived-At: On Fri, Aug 28, 2015 at 06:39:32PM +0700, Рысь wrote: > On Fri, 28 Aug 2015 09:24:22 +0200 > u-wsnj@aetey.se wrote: > > > > I don't think the status quo is a reasonable option. We should > > > either teach GCC that musl targets don't support symbol versioning, > > > and make sure apps/libs' build systems detect this, or we should > > > make them work. My leaning is towards the latter. > > > > I'd rather prefer the former. Otherwise supporting an approach chosen > > for unrelated reasons somewhere else imposes a certain complexity > > cost on musl and on any packager/integrator who does not need > > versioning. > > > > Rune > > > > I agree with this too. What are the real reasons raised to reconsider > support for symbol versioning? How other not glibc build environments > currently handle them? The real reasons are what I said: - Internal use by some software of versioned symbols, e.g. in libgcc. I would not call this as packaging/integration issue because it's not solved by using matching library versions at runtime. It requires internal changes that are not formulatic but require individual consideration for any software affected to develop and alternate solution. - Presumed (I haven't tested this) breakage using C++ programs built with different GCC versions (and maybe even just different -std options?) with the latest libstdc++. Symbol versioning actually can't make this work when there are multiple C++ shared libraries in the same program built with different libstdc++ versions, but people generally know C++ is ABI-hell and static link most of all of the C++ code, only using dynamic linking for C libraries, and in that case symbol versioning _should_ be sufficient to make it work safely. Unlike the first issue, this issue _could_ be addressed at he packaging/integration level by making different SONAMEs for different libstdc++ versions/ABIs, or different library paths for different apps, and I'm aware that Rune is doing something like this, but I don't think it's reasonable to tell users they have to deviate heavily from upstream GCC intent to make this work. - Silent breakage in various libraries that use symbol versioning and break their ABIs. As I've said before, symbol versioning does NOT solve this problem correctly or safely, but the chance of nasty, dangerous blow-up is much higher when apps/libs _think_ they have symbol versioning at their disposal but it doesn't actually work. This issue (unlike the above 2) could probably be fixed by teaching the toolchain that musl does not support versioned symbols, but I have no real-world information on how many libs would fallback to some other solution (SONAMEs?) vs simply refusing to build. As I've said I'm confident in my existing conclusion that symbol versioning was a misfeature and that it's not something musl should use. But however dubious it is, it's a dynamic-linking behavior that a fair amount of software expects should work. The only potential cost of supporting it is some impact on dynamic linking time, which I'll of course work to minimize if we support it. Code size impact is negligible IMO. BTW there is also one use for symbol versioning that's semi-legitimate and not related to mixing ABIS; I believe glibc makes use of this. If you have a family of related shared libraries and want to provide some symbols for private interfaces between them, you can use a non-default version. This prevents the symbol from being linkable by ld without specifying a specific version (e.g. so configure scripts won't detect the presence of the symbol). I would rather this feature have never existed, but it does exist, and software that uses it is not doing anything sketchy with mixing of incompatible ABIs via versioning; it's just using the mechanism to achieve a different result. Rich