Re: Adjustments to roadmap

[Rich Felker <dalias@libc.org>]

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