From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13643 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: Symbol versioning approximation trips on compat symbols Date: Thu, 24 Jan 2019 10:28:46 +0100 Message-ID: <20190124092846.GA30123@example.net> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="1402"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-13659-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 24 10:29:20 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1gmbK4-0000FJ-4g for gllmg-musl@m.gmane.org; Thu, 24 Jan 2019 10:29:20 +0100 Original-Received: (qmail 17970 invoked by uid 550); 24 Jan 2019 09:29:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17945 invoked from network); 24 Jan 2019 09:29:16 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=x.fripost.org; h= in-reply-to:content-disposition:content-type:content-type :mime-version:references:message-id:subject:subject:from:from :date:date; s=9df9cdc7e101629b5003b587945afa70; t=1548322145; x= 1550136546; bh=JsPdpAjZqTYtKXH3YTXMfD+cPk/will1mQeyAtpjNpU=; b=I ImohkBokDspS0K4vUmDRj6FBhaKMRf7yAfGY8Z2mMswpZuzw9kf68W4gcisn4VOD FCy19XltAv4QQlOWYSA2a+ISotTKMO4+MsWynY2OWlZPz67wEP4j6d7Ku6sFGHbY KanKpSed14HF51TG2efYYOcGepTe4umaRBTMlQ7dtvoBrjfsOccRJ36tfcD3nRe3 NutMO3Pi5EK+j1/BpZxRPDMW6/ZoOeMX+MzxMCG58c4wSynHpbkz2Eli6dWomnvy 6xKppigtrQS0wIvjJlBeBUufSbbDF66PYInJYR0gPCLUT+0NM3kYXVJg/6OcfH4o nJHSIOwbhai63ISfxX18Q== X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline In-Reply-To: <20190124014340.GV23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13643 Archived-At: On Wed, Jan 23, 2019 at 08:43:40PM -0500, Rich Felker wrote: > The same issue came up before with libgcc defining and referencing a > non-default-version symbol for some weird compatibility hack. I don't > remember the details but Szabolcs Nagy was involved in investigating > and might. In any case, the root cause is that musl's dynamic linker > does not support symbol versioning; for the sake of being able to load > libraries that were build with versioning, it always resolves a symbol > to the "latest"/default version, the same as ld would do at link time. > Normally this is the right thing as long as you don't actually have > things that were linked against an old incompatible version, but it > also breaks explicit linking to a particular version as in your > example above. > > The right fix is probably to add support for symbol version matching > in the dynamic linker. Unfortunately this involves some extra logic in > the extreme hot paths, so it's hard to make the cost unobservably low, > and last I checked some members of the community were opposed to it on > ideological grounds. If there's a good need for it (and I think just IMVHO symbol versioning is basically aimed to hide the complexity of the evolution of libraries, to make certain usage cases "just work". OTOH it does not reduce the complexity under the hood but rather adds some extra of it. That's why I see its impact as double negative, postulating more complex tools and reducing the capacity of fellow integrators to analyze their systems. > avoiding silent breakage of third-party libs using versioning and > intending for it to work is a fairly good one already), support can be > added, but doing it without negative impact is a pretty big task. This cost itself (of adding the support) means that some other useful changes in musl will be missing at _every_ given time in the future development. Is this workaround, for the sake of libraries who do unusual hacks, really so important? Rune