[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
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.
