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.