[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 31 Aug 2015 00:13:29 +0700
From: Рысь <lynx@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Sun, 30 Aug 2015 01:30:37 -0400
Rich Felker <dalias@...c.org> 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.
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.
>
> > 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).
The "GNU/Linux" already crossed some points of no return, some
fundamental even a decade ago. And you can name some of them. And even
because of them musl is gaining attention as alternative libc and
forming a crowd of those who prefer "green organic Linux product" :-)
>
> > 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.
The support for static linking indeed must be always available with
musl. However some programs are designed with dynamic linking in mind,
and some even require dangerous mechanisms like dlopen. And symvers is
a deeper level of hell.
I myself consider such programs or libraries (more common) broken
anyway (they usually break the build after for silly reasons like
binding hard to glibc internals), and if I can't proceed without them
(for example, alsa) a huge local patchwork takes place.
Btw your wiki page about alternatives is a good collection here.
>
> > 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. I hope you will continue to consider symvers a misfeature then.
>
> > 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)
Btw who decided arm64 to be such a stupid name?
>
> > 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.
OK.
>
> 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.
