Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 30 Aug 2015 11:00:13 +0200
From: Szabolcs Nagy <>
Subject: Re: Adjustments to roadmap

* Rich Felker <> [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.