From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13669 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: (OT?) Re: [musl] Symbol versioning approximation trips on compat symbols Date: Mon, 28 Jan 2019 10:29:12 -0500 Message-ID: <20190128152912.GB23599@brightrain.aerifal.cx> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> <20190124110931.GU21289@port70.net> <87sgxi718r.fsf@oldenburg2.str.redhat.com> <20190127040424.GA23599@brightrain.aerifal.cx> <20190127093650.GB30123@example.net> <87bm41xpce.fsf@oldenburg2.str.redhat.com> <20190128130813.GC30123@example.net> 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="183101"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) To: musl@lists.openwall.com Original-X-From: musl-return-13685-gllmg-musl=m.gmane.org@lists.openwall.com Mon Jan 28 16:29:27 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 1go8ql-000lY5-Gg for gllmg-musl@m.gmane.org; Mon, 28 Jan 2019 16:29:27 +0100 Original-Received: (qmail 31905 invoked by uid 550); 28 Jan 2019 15:29:25 -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 31884 invoked from network); 28 Jan 2019 15:29:24 -0000 Content-Disposition: inline In-Reply-To: <20190128130813.GC30123@example.net> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:13669 Archived-At: On Mon, Jan 28, 2019 at 02:08:13PM +0100, u-uy74@aetey.se wrote: > On Mon, Jan 28, 2019 at 07:34:25AM +0100, Florian Weimer wrote: > > * u-uy: > > > > > On Sat, Jan 26, 2019 at 11:04:24PM -0500, Rich Felker wrote: > > >> For what it's worth, compat symbols would have let us remove symbols > > >> that shouldn't have been put in musl, such as lchmod (which confuses > > >> broken apps which wrongly expect that, if it exists, it should work) > > > > > > For what my integrator perspective is worth, exposing brokenness instead > > > of catering for it is a Good Thing. > > > So far, no one has presented a compelling way how to test for symbol > > versioning support. > > My comment apparently fell out of context. Sorry for that. > > It was about applications who make undue assumptions (and as a consequence > use misdirected tests). Exposing the failures of those assumptions is > vital to be able to make it better. > > If there is a feature which is hard or impossible to test for, like > symbol versioning, it means that the applications may _have_ to rely on > an explicit build flag telling whether to use it. > > IOW it is for the most part not a technical problem but rather a problem > of awareness among application developers. It wouldn't be hard to test for if toolchains had been consistent with musl capabilities all along. They have not been. So we have a situation where the valid build-time tests indicate support, but runtime silently lacks it. I don't think this is a good situation to have created, and it's not fixable by telling the toolchains "no, we don't actually have that" because there are and will be deployed toolchains that don't know/honor that for a long time. Fortunately, it mostly doesn't matter since the main intended usage for versioning is to link to the current/default version symbols, assuming your apps are all up-to-date with respect to your libs (and libs wrt each other). But I still think honoring version bindings in ldso is the right course of action. Rich