[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150828171818.GC7833@brightrain.aerifal.cx>
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.
