[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Aug 2015 11:00:13 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: Adjustments to roadmap
* Rich Felker <dalias@...c.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
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).
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.
