Re: Undefined use of weak symbols in gnulib

[Florian Weimer]

* Paul Eggert:

> On 4/26/21 10:53 PM, Florian Weimer via Libc-alpha wrote:
>> This will become an urgent issue with glibc 2.34, which defines
>> pthread_mutexattr_gettype unconditionally.  Certain gnulib modules will
>> stop working until the binaries are relinked.
>
> Thanks for mentioning this. But in what sense will the modules stop
> working? I'm a little lost.
>
> glibc 2.34 also defines pthread_once unconditionally, right? So why
> doesn't code like this:
>
>   if (pthread_mutexattr_gettype != NULL)
>     pthread_once (control, callback);
>
> continue to work in 2.34?

The link editor does not emitted a relocation referencing the
pthread_once symbol.  The function address in the GOT is always zero.
It does not matter if a pthread_once symbol exists at run time because
their is no reference to it.  Relinking the executable will of course
fix this and generate a reference to the pthread_once symbol, but
relinking is required.

For example, bison 3.7.4 built against glibc 2.33 has these pthread*
symbol references in its dynamic symbol table on powerpc64le-linux-gnu:

   58: 0000000000000000      0 FUNC    WEAK   DEFAULT    UNDEF 
pthread_mutex_init@GLIBC_2.17 (2)
  117: 0000000000000000      0 FUNC    WEAK   DEFAULT    UNDEF 
pthread_mutex_lock@GLIBC_2.17 (2)
  118: 0000000000000000      0 NOTYPE  WEAK   DEFAULT    UNDEF 
pthread_mutexattr_gettype
  120: 0000000000000000      0 FUNC    WEAK   DEFAULT    UNDEF 
pthread_mutex_unlock@GLIBC_2.17 (2)

pthread_once is just not there.

Thanks,
Florian