[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150830044654.GJ7833@brightrain.aerifal.cx>
Date: Sun, 30 Aug 2015 00:46:54 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Sun, Aug 30, 2015 at 11:21:28AM +0700, Рысь wrote:
> 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.
No, I don't, mainly because I don't ascribe that level of
self-importance to musl. :-) People who are using misguided features
like symbol versioning are not making the decision to do so based on
whether or not musl supports them. And there are already good reasons
to argue against use of symbol versioning aside from "it doesn't work
with musl" such as how it interacts with static linking.
As for your concern about "being unable to patch it out", if you're
running correct/matching library versions for your apps so they don't
need old symbol versions, the worst that should happen from "turning
back off" version support in musl ldso would be that libgcc_s breaks
(due to the internal use of a non-public version); then you just go
and patch libgcc_s not to do this.
If on the other hand you _do_ have mismatched library versions such
that old symbol versions are needed, then right now you've got silent
breakage with musl; if we supported versions and then you went and
patched that out, you'd just end up back where we are now, but not
with any new breakage.
Does that adequately address your concerns?
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.
