Re: Trouble with portable linking

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

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