[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Aug 2015 12:13:53 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Sun, 30 Aug 2015 00:46:54 -0400
Rich Felker <dalias@...c.org> wrote:
> 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
The snowball effect I referred to is that your silent decision will
amplify in future by allowing third parties to use symvers more and
more in their code, then it will be so widespread it will be impossible
to run anything without them. Instead, you and community as an
alternative to glibc should teach them not to do. This is not a purely
technical talk, sorry. You can't refere to pure technical reasons here.
Why you want to be clean and straight in the area where hacks are in
general use?
For myself I already did everything in my systems to be sure that there
is no such treat as "symbol versioning": patching binutils ld not to
accept them, then patching every thing which silently requires them
(alarmed by build failures in this way of course). I also do not use
recent gcc, so I don't know which problems have arised again and why
now again "libgcc_s breaks" (and why I don't even have it in my
systems, both "desktop" and "server" configurations which include C++
complex code like qt4).
I do care about future musl compatibility with existing code. All that
new stuff is great and I tested 1.1.10 works on my systems without
breakage, but when I hear "symbol versioning" that causes some fear
despite I think it's only local hacks to support some gcc madness again
(right?).
I did fight with glibc symvers long time before to just forget about
this always arising treat. Personally, I think symvers is a child of
hell and always should be avoided and projects who use them should be
teached about dangers.
I also understand people who just don't know what "symbol versioning"
is, but musl usage is mainly embedded plus those ideal desktops and
alike built by those who know Linux more beyond "how to build kernel".
And Linux itself never was a system which can be universally plugged in
everywhere (or we'd have a non-configurable kernel).
And how other non-glibc build environments solve libgcc_s breakage?
Or they dead already?
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.
