Re: Trouble with portable linking

[Florian Weimer <fw@deneb.enyo.de>]

* Ryan Burn:

> On Thu, Dec 17, 2020 at 12:55 PM Florian Weimer <fw@deneb.enyo.de> 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 “Version needs” 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