Trouble with portable linking

Trouble with portable linking

[Ryan Burn]

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?

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?

Re: Trouble with portable linking

[Florian Weimer]

* 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.

Re: Trouble with portable linking

[Ryan Burn]

On Thu, Dec 17, 2020 at 12:14 PM Florian Weimer <fw@deneb.enyo.de> wrote:

>
> 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.

Thanks for the response! Could you elaborate a little more on how I
can build the stub library?

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? Then it would work with both newer and older versions of
glibc, right?

Re: Trouble with portable linking

[Florian Weimer]

* Ryan Burn:

> On Thu, Dec 17, 2020 at 12:14 PM Florian Weimer <fw@deneb.enyo.de> wrote:
>
>> 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.
>
> Thanks for the response! Could you elaborate a little more on how I
> can build the stub library?

Here's a script that generates such a stub DSO from an existing full
DSO:

<https://git.centos.org/rpms/compat-glibc/blob/c7/f/SOURCES/dummylib.sh>

It is not completely correct for data symbols; that part needs a bit
of tweaking to get the alignment right.  The resulting assembler file
is architecture-specific because the object sizes and symbol versions
are.

> 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.

Re: Trouble with portable linking

[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?

Is there any way to view embedded sonames using objdump or readelf?

Re: Trouble with portable linking

[Florian Weimer]

* 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