Date: Fri, 28 Aug 2015 13:18:18 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Adjustments to roadmap On Fri, Aug 28, 2015 at 06:39:32PM +0700, Рысь wrote: > On Fri, 28 Aug 2015 09:24:22 +0200 > u-wsnj@...ey.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
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.