Re: Adjustments to roadmap

[Rich Felker <dalias@libc.org>]

On Sun, Aug 30, 2015 at 11:00:13AM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-08-30 01:30:37 -0400]:
> > On Sun, Aug 30, 2015 at 12:13:53PM +0700, ???????? wrote:
> > > 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
> 
> the libgcc_s issue is x86 specific (because only x86 had the
> broken ifunc based multiversioning support)
> 
> it is possible to patch out, but would make it impossible to
> use musl-gcc wrapper with existing gcc-6.* on x86

I don't think this is an actual concern. musl-gcc should insist on
using static libgcc. If it doesn't, that's a bug: libgcc_s.so.1 isn't
even going to be present in the musl library path unless the user
manually copies/links it there.

> there are other reasons for symvers: debian is willing to
> accept patches for a musl based debian, however they use
> symbol versioning a lot to avoid frequently changing the .so
> name.  i.e. if we support symvers we may be able to create
> a musl based debian package repo without much effort or
> maintainance work. (it is probably possible to rebuild all
> dependent packages on every minor abi change in a library,
> but then somebody would need to do that work and users will
> need to download more packages on an update).

This seems like an area where there would be concrete benefit. Any
word from ppl interested in Debian/musl?

Being that the only significant feedback on symbol versioning so far
has been negative, I lean towards holding off on prioritizing this
issue while we wait for more opinions or compelling reasons to support
it. It would be nice if the libgcc issue could be fixed independently
of version support so that it's not compelling a particular course of
action on our side; I think the alternatives you proposed on the gcc
side were cleaner than what they're doing now anyway. But I'm
concerned we may not be able to get upstream to accept them.

Rich