From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from albireo.enyo.de (albireo.enyo.de [37.24.231.21]) by sourceware.org (Postfix) with ESMTPS id 4626A3851C3D for ; Thu, 17 Dec 2020 20:14:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 4626A3851C3D Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=deneb.enyo.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=fw@deneb.enyo.de Received: from [172.17.203.2] (helo=deneb.enyo.de) by albireo.enyo.de with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) id 1kpzfi-0007pM-RF; Thu, 17 Dec 2020 20:14:46 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1kpzfb-0004a5-Bb; Thu, 17 Dec 2020 21:14:39 +0100 From: Florian Weimer To: Ryan Burn via Libc-help Subject: Re: Trouble with portable linking References: Date: Thu, 17 Dec 2020 21:14:39 +0100 In-Reply-To: (Ryan Burn via Libc-help's message of "Thu, 17 Dec 2020 11:57:35 -0800") Message-ID: <87lfdwdwb4.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-6.2 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: libc-help@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-help mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Dec 2020 20:14:51 -0000 * Ryan Burn via Libc-help: > Hello, I'm trying to link a portable shared library binary. I've > followed the practice recommended here > (https://stackoverflow.com/questions/4032373/linking-against-an-old-version-of-libc-to-provide-greater-application-coverage/20065096#20065096) > where I explicitly link to portable versions of symbols, and it's > worked well for me. But the recent change where pthread_getattr_np > moved from libpthread to libc is causing me trouble: > > https://stackoverflow.com/questions/65336219/how-to-link-so-that-pthread-getattr-np-will-be-resolved > > When my portable binary is loaded on an older system where > pthread_getattr_np is still in libpthread, loading fails to resolve > the symbol. Could anyone suggest how I can work around this? If you want to be compatible with glibc versions that check the embedded soname in symbol versions (which is not visible in the @ syntax), you need to build a stub library that defines the required symbol versions in the right shared object. There is no way to achieve this with .symver directives. Alternatively, you could convince more distributions to backport commit f0b2132b35248c1f4a80f62a2c38cddcc802aa8c ("ld.so: Support moving versioned symbols between sonames [BZ #24741]"). > Also, is there a reason why the portable versioned symbol > pthread_getattr_np@GLIBC_2.2.5 moved from libpthread to libc? Why not > keep pthread_getattr_np@GLIBC_2.2.5 in libpthread and have the newer > symbol in libc? We would have to create an internal alias in libc and export for use in libpthread. The additional function call seemed unnecessary. IFUNC resolvers are not usable for such forwarders because they must not depend on relocations, and the symbol reference to libc.so.6 is such a dependency.