[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Aug 2015 13:38:10 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
On Mon, Aug 31, 2015 at 12:13:29AM +0700, Рысь wrote:
> 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.
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
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.
