From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8420 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Adjustments to roadmap Date: Sun, 30 Aug 2015 13:38:10 -0400 Message-ID: <20150830173810.GP7833@brightrain.aerifal.cx> References: <20150828024347.GA7624@brightrain.aerifal.cx> <20150828072422.GE11263@example.net> <20150828183932.0f03a8d5@r2lynx> <20150828171818.GC7833@brightrain.aerifal.cx> <20150830112128.77511bbc@r2lynx> <20150830044654.GJ7833@brightrain.aerifal.cx> <20150830121353.71d24c36@r2lynx> <20150830053037.GK7833@brightrain.aerifal.cx> <20150831001329.191af2c2@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1440956307 4993 80.91.229.3 (30 Aug 2015 17:38:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 17:38:27 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8432-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 30 19:38:26 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZW6Yj-00068O-VP for gllmg-musl@m.gmane.org; Sun, 30 Aug 2015 19:38:26 +0200 Original-Received: (qmail 32216 invoked by uid 550); 30 Aug 2015 17:38:24 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 32193 invoked from network); 30 Aug 2015 17:38:23 -0000 Content-Disposition: inline In-Reply-To: <20150831001329.191af2c2@r2lynx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8420 Archived-At: On Mon, Aug 31, 2015 at 12:13:29AM +0700, Рысь wrote: > On Sun, 30 Aug 2015 01:30:37 -0400 > Rich Felker wrote: > > > On Sun, Aug 30, 2015 at 12:13:53PM +0700, Рысь wrote: > > > 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, > > > > This is what I don't buy. You're seriously overestimating the degree > > to which people doing this care about musl. Most likely they are not > > even aware of musl; much less do they care if I tell them they can't > > use symbol versioning. > > Do they listen to reasons or just reject claims in "drepper" style? > That's sad, I understand it's hard to change anything, especially in > gcc/gnu camp. The GCC/GNU side is actually a lot easier to work with these days. Anecdotally I've had the most bad responses ("it works for me with glibc", "static linking is deprecated", etc.) from the "desktop Linux" sector. > But musl already made it's way into OpenWRT trunk and some news shouted > already. Even if they're not aware, some will face it in niche products. Generally the projects actively trying to support musl are those that are either already following best practices on things like this, or at least aware of where they're not and conscious of not actively breaking things. > > > 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). > > > > That's a perfectly fine approach, and if that's your setup, no harm > > can come from patching hypothetical symver support out of musl since > > there are no symbol versions present to begin with. > > OK. If symvers hack goes only into dynamic linker, that's no more than > a commit that I (if I want to cutoff such a code like binutils ld) can > revert. It may not be quite that easy since future commits will build on code with some extra arguments, local vars, etc. and not cleanly apply with that reverted. You'd probably have an easier time finding a clever way to make the code optimize-out with dead code elimination by adding a single line somewhere to null-out the version table pointer or similar. > I hope you will continue to consider symvers a misfeature then. 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). > > > > This is not an option for everyone. For example your version of gcc > > does not have aarch64 support, nor does it have risc-v support which > > is not even in upstream gcc yet afaik, and which will be very > > important for future open hardware that free and auditable all the way > > down to the metal. Backporting new archs or features from new language > > standards to old gcc is A LOT of work. I would love to see somebody do > > it, but I'm not going to be the one who does. > > (unneeded text with blaming gcc so fat/slow/hard to configure) Bloat, C++, lib dependencies, etc. are certainly valid complaints, but from my perspective the build process has gotten a lot better. Cross compilers and sysroot used to be very fragile and had some outright breakage in the build system that required arcane workarounds; now they just work fine out of the box. Aside from the excessive build time and disk space, I'd much rather be working with gcc 5.2 than 4.2. The time cost to me fixing all the stupid stuff that breaks on old gcc is greater than the cpu time cost compiling new gcc... Of course I understand and respect that the situation is the opposite for many users. I just don't have the time/resources to clean up and revamp old gcc for them, tho. :( > Btw who decided arm64 to be such a stupid name? arm64 was not usable because so much stuff matches arm* to catch armv4t, armv5, armv6, etc. and it would wrongly identify arm64 as being the existing arm arch rather than a new one. Rich