[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150830112128.77511bbc@r2lynx>
Date: Sun, 30 Aug 2015 11:21:28 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Fri, 28 Aug 2015 13:18:18 -0400
Rich Felker <dalias@...c.org> wrote:
> 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
Don't you think that the snowball effect will be later in future so much
amplified by this decision so that it will not be even able to be
patched out? Well, then, that's why I prefer to use old stable versions
which do not suffer from these virtual problems.
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.
