From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13644 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Florian Weimer Newsgroups: gmane.linux.lib.musl.general Subject: Re: Symbol versioning approximation trips on compat symbols Date: Thu, 24 Jan 2019 11:11:27 +0100 Message-ID: <87a7jq8iwg.fsf@oldenburg2.str.redhat.com> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> <20190124092846.GA30123@example.net> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="189837"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: musl@lists.openwall.com To: u-uy74@aetey.se Original-X-From: musl-return-13660-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 24 11:11:45 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 1gmbz6-000nKQ-L4 for gllmg-musl@m.gmane.org; Thu, 24 Jan 2019 11:11:44 +0100 Original-Received: (qmail 9654 invoked by uid 550); 24 Jan 2019 10:11:42 -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 9636 invoked from network); 24 Jan 2019 10:11:42 -0000 In-Reply-To: <20190124092846.GA30123@example.net> (u-uy's message of "Thu, 24 Jan 2019 10:28:46 +0100") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.27]); Thu, 24 Jan 2019 10:11:30 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:13644 Archived-At: * u-uy: > 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. That's certainly a valid position to take. But the reality is that all toolchains that target musl have symbol versioning support built into them today, just not in the dynamic linker. It would be far easier unrelated upstreams if the toolchain simply did not support symbol versioning at all (because the dynamic linker does not support it, so it's not usable in each place where it is required anyway). Then a simple check for .symver support in the assembler would tell us whether we can symbol versionining or not. I have no idea how this current support is supposed to work, particularly with cross-compiling. Does everyone have to write configure hacks for *-musl targets to disable symbol versioning support? That goes against the mantra of testing what you use (and avoid hard-coded knowledge about specific versions/targets). Thanks, Florian