From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8388 Path: news.gmane.org!not-for-mail From: u-wsnj@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Adjustments to roadmap Date: Fri, 28 Aug 2015 09:24:22 +0200 Message-ID: <20150828072422.GE11263@example.net> References: <20150828024347.GA7624@brightrain.aerifal.cx> 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 1440746705 17796 80.91.229.3 (28 Aug 2015 07:25:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 28 Aug 2015 07:25:05 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-8400-gllmg-musl=m.gmane.org@lists.openwall.com Fri Aug 28 09:24:59 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 1ZVE1w-00040f-Bf for gllmg-musl@m.gmane.org; Fri, 28 Aug 2015 09:24:56 +0200 Original-Received: (qmail 7816 invoked by uid 550); 28 Aug 2015 07:24:54 -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 7798 invoked from network); 28 Aug 2015 07:24:54 -0000 X-T2-Spam-Status: No, hits=0.8 required=5.0 tests=BAYES_50 Received-SPF: none receiver=mailfe02.swip.net; client-ip=178.16.208.57; envelope-from=u-wsnj@aetey.se Content-Disposition: inline In-Reply-To: <20150828024347.GA7624@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:8388 Archived-At: On Thu, Aug 27, 2015 at 10:43:48PM -0400, Rich Felker wrote: > 3. Symbol versioning > > Right now musl's dynamic linker ignores symbol versioning information > except to select the "current" version of a symbol the same way ld > does. This is sufficient for most things, if you don't want to support > old library ABIs and mixed (i.e. broken) ABIs, but it breaks some > hacks GCC is doing in their target libs (libgcc_s.so, ...), and some > setups that arguably "should" work, especially for C++ apps. What's > probably worse is that you get silent breakage when an app is trying > to use symbol versioning, expecting it to work, and it doesn't. The symbol versioning is hardly the only or most straightforward or most efficient way to manage ABI contracts between multiple parties. I feel that it emerged to mitigate problems created by traditional deployment practices. "Traditional" implies "formed in the past, given differing prerequisites", aka suboptimal. I our deployments symbol versioning is fully redundant, I'm happy not having to deal with it with musl. > I don't think the status quo is a reasonable option. We should either > teach GCC that musl targets don't support symbol versioning, and make > sure apps/libs' build systems detect this, or we should make them > work. My leaning is towards the latter. I'd rather prefer the former. Otherwise supporting an approach chosen for unrelated reasons somewhere else imposes a certain complexity cost on musl and on any packager/integrator who does not need versioning. Rune