From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13686 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: u-uy74@aetey.se Newsgroups: gmane.linux.lib.musl.general Subject: Re: (OT?) Re: [musl] Symbol versioning approximation trips on compat symbols Date: Tue, 29 Jan 2019 18:13:05 +0100 Message-ID: <20190129171305.GA22427@example.net> 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> <20190128152912.GB23599@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="56124"; mail-complaints-to="usenet@blaine.gmane.org" To: musl@lists.openwall.com Original-X-From: musl-return-13702-gllmg-musl=m.gmane.org@lists.openwall.com Tue Jan 29 18:13:54 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 1goWxO-000EUj-Dw for gllmg-musl@m.gmane.org; Tue, 29 Jan 2019 18:13:54 +0100 Original-Received: (qmail 3904 invoked by uid 550); 29 Jan 2019 17:13:52 -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 3885 invoked from network); 29 Jan 2019 17:13:51 -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=1548782019; x= 1550596420; bh=8ZvQf2WbMT580YN6eKW/AyDjK12EVUguw0kK7saayD8=; b=m gPho6Qz8KqlPNtqROHyL1YUUTkyaNZ6tigNbGZ/8khOmfHPu1Ye5kwJO/6EmWxjU Y9CSS0yHvkILUOlCMrxe0lTITcm4dLVdv/XYp8fXckQ8j4Jf7f6WWn9Bg1SB1pSa U76JJGzcdz7eyVJOzmiNITG/poSl+fltnY0IEFpqMvD1y9AinfvkB2V0b39w1qC9 5ezmYAKXukyqNgzs4WNHjifXJZR/ZRuMjunDRK9c2uU2zQnegA0216XM4L7FDXS9 TVIta4HiDA3p28XkmbL8rx+QC2kdQX3i2YZhPJ5i13baDijqgQXD6hsMN9e8QLwc gi3nfHPHYJK4yk6nwTv/A== X-Virus-Scanned: Debian amavisd-new at fripost.org Content-Disposition: inline In-Reply-To: <20190128152912.GB23599@brightrain.aerifal.cx> Xref: news.gmane.org gmane.linux.lib.musl.general:13686 Archived-At: On Mon, Jan 28, 2019 at 10:29:12AM -0500, Rich Felker wrote: > On Mon, Jan 28, 2019 at 02:08:13PM +0100, u-uy74@aetey.se wrote: > > 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. > 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 What is the value (the "validity"?) of a build-time test if it does not help to distinguish how to build a usable binary? This seems to be testing for A when we want to know B. > 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. I assume you'll find a good balance between the cost/complexity and usefulness. (Musl is by far the best libc I ever worked with on Linux, among others omitting a number of regrettably popular misfeatures. Kudos.) Rune