Date: Sun, 30 Aug 2015 13:09:32 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Re: Adjustments to roadmap On Sun, Aug 30, 2015 at 11:00:13AM +0200, Szabolcs Nagy wrote: > * 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 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
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.