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 3A6163938398 for ; Fri, 18 Dec 2020 07:48:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A6163938398 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 1kqAV9-00030v-GA; Fri, 18 Dec 2020 07:48:35 +0000 Received: from fw by deneb.enyo.de with local (Exim 4.92) (envelope-from ) id 1kqAV9-0002Zh-Ce; Fri, 18 Dec 2020 08:48:35 +0100 From: Florian Weimer To: Ryan Burn Cc: Ryan Burn via Libc-help Subject: Re: Trouble with portable linking References: <87lfdwdwb4.fsf@mid.deneb.enyo.de> <87zh2ccfv0.fsf@mid.deneb.enyo.de> Date: Fri, 18 Dec 2020 08:48:35 +0100 In-Reply-To: (Ryan Burn's message of "Thu, 17 Dec 2020 13:08:07 -0800") Message-ID: <87im8zd06k.fsf@mid.deneb.enyo.de> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-6.1 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: Fri, 18 Dec 2020 07:48:38 -0000 * Ryan Burn: > On Thu, Dec 17, 2020 at 12:55 PM Florian Weimer wrote: > >> > If I understand correctly, newer versions of glibc will resolve a >> > versioned symbol even if the embedded soname doesn't match. Is there a >> > way to explicitly define the soname so that I can specify it to >> > libpthread? >> >> The link editor copies the soname of the shared object that contains a >> versioned symbol definition when it generates the versioned symbol >> reference. That's why I think you need that stub DSO. It's the only >> way I know of that actually works. > > What if I link a minimal static library libstub.a like this > > // stub.c > __asm__(".symver pthread_getattr_np,pthread_getattr_np@GLIBC_2.2.5"); > > int __wrap_pthread_getattr_np(pthread_t thread, pthread_attr_t* attr) { > return pthread_getattr_np(thread, attr); > } > > On an older machine where libpthread contains the symbol and then add > libstub.a when I link my DSO in the newer build environment? Would > that work or is the embedded soname determined at the final linking > stage? It's determined at the final link. So I don't think this will work. > Is there any way to view embedded sonames using objdump or readelf? readelf -aW shows them in the =E2=80=9CVersion needs=E2=80=9D section: Version needs section '.gnu.version_r' contains 2 entries: Addr: 0x0000000000004df8 Offset: 0x004df8 Link: 5 (.dynstr) 000000: Version: 1 File: ld-linux-x86-64.so.2 Cnt: 2 0x0010: Name: GLIBC_2.2.5 Flags: none Version: 18 0x0020: Name: GLIBC_PRIVATE Flags: none Version: 17 0x0030: Version: 1 File: libc.so.6 Cnt: 5 0x0040: Name: GLIBC_2.14 Flags: none Version: 19 0x0050: Name: GLIBC_2.3.2 Flags: none Version: 16 0x0060: Name: GLIBC_2.4 Flags: none Version: 15 0x0070: Name: GLIBC_2.2.5 Flags: none Version: 14 0x0080: Name: GLIBC_PRIVATE Flags: none Version: 13