From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8416 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: Adjustments to roadmap Date: Sun, 30 Aug 2015 13:09:32 -0400 Message-ID: <20150830170932.GN7833@brightrain.aerifal.cx> References: <20150828024347.GA7624@brightrain.aerifal.cx> <20150828072422.GE11263@example.net> <20150828183932.0f03a8d5@r2lynx> <20150828171818.GC7833@brightrain.aerifal.cx> <20150830112128.77511bbc@r2lynx> <20150830044654.GJ7833@brightrain.aerifal.cx> <20150830121353.71d24c36@r2lynx> <20150830053037.GK7833@brightrain.aerifal.cx> <20150830090009.GH3609@port70.net> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1440954593 10331 80.91.229.3 (30 Aug 2015 17:09:53 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 30 Aug 2015 17:09:53 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8428-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 30 19:09:49 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1ZW671-0000lI-LV for gllmg-musl@m.gmane.org; Sun, 30 Aug 2015 19:09:47 +0200 Original-Received: (qmail 2004 invoked by uid 550); 30 Aug 2015 17:09:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 1986 invoked from network); 30 Aug 2015 17:09:45 -0000 Content-Disposition: inline In-Reply-To: <20150830090009.GH3609@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:8416 Archived-At: On Sun, Aug 30, 2015 at 11:00:13AM +0200, Szabolcs Nagy wrote: > * 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 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