From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/13646 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 12:18:12 +0100 Message-ID: <87sgxi718r.fsf@oldenburg2.str.redhat.com> References: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> <20190124014340.GV23599@brightrain.aerifal.cx> <20190124110931.GU21289@port70.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="209160"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) To: musl@lists.openwall.com Original-X-From: musl-return-13662-gllmg-musl=m.gmane.org@lists.openwall.com Thu Jan 24 12:18:30 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 1gmd1h-000sJu-7l for gllmg-musl@m.gmane.org; Thu, 24 Jan 2019 12:18:29 +0100 Original-Received: (qmail 3689 invoked by uid 550); 24 Jan 2019 11:18:27 -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 3665 invoked from network); 24 Jan 2019 11:18:26 -0000 In-Reply-To: <20190124110931.GU21289@port70.net> (Szabolcs Nagy's message of "Thu, 24 Jan 2019 12:09:32 +0100") X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.39]); Thu, 24 Jan 2019 11:18:14 +0000 (UTC) Xref: news.gmane.org gmane.linux.lib.musl.general:13646 Archived-At: * Szabolcs Nagy: > but it turned out to be broken (ifunc resolvers may run before > relocations for the extern object are processed), so the symbol > was removed (moved to libgcc.a), but a compat symbol (@) was > kept around and the ctor of libgcc_s.so.1 still references it. I assume we cannot use a hidden alias to eliminate the symbolic reference because it is a data symbol, so copy relocations are a possibility and with the hidden alias, the constructor would update the wrong object? > i wonder what is the use-case for using a compat symbol without > introducing a new default version for the symbol in general? A compat symbol can be implemented by a different library, and applications can link to the symbol and get it from the new library. Mostly it is just for documenting intent, marking the symbol as deprecated. It's still relatively easy to link to the symbol from new binaries (even without resorting to dlvsym). Thanks, Florian