Date: Sun, 30 Aug 2015 01:30:37 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Adjustments to roadmap 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. > then it will be so widespread it will be impossible > to run anything without them. That hasn't happened yet despite the people who use it only caring about "GNU/Linux" (glibc). > 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? I think there's a good opportunity for education not to use symbol versioning just when people ask why musl libc.so itself doesn't have versions or why they can't use versioning to achieve something musl-internal. There's certainly also _some_ weight to be had in filing bug reports that say "this is breaking when you run it on musl libc because it uses symbol versioning", but it seems a lot more likely to me that this just becomes a disincentive for them to address any musl-related bug reports. They can come back and say "symbol versions are a documented ELF feature in the toolchain, and if musl's ldso doesn't support them it's broken". I disagree with this view, but it's a plausible position they can take. So from my standpoint, "we support this misfeature despite it being a misfeature, but you really should make things work without it because static linking is broken, and our users need static linking" is a much more diplomatic argument. > 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. > 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. > And how other non-glibc build environments solve libgcc_s breakage? > Or they dead already? This use of versions is Linux/ELF-specific, and the only other player, uClibc, supports symbol versioning AFAIK. 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.