[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Undefined use of weak symbols in gnulib

From: Florian Weimer
Subject: Re: Undefined use of weak symbols in gnulib
Date: Tue, 27 Apr 2021 08:58:36 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)

* 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 
  120: 0000000000000000      0 FUNC    WEAK   DEFAULT    UNDEF 
pthread_mutex_unlock@GLIBC_2.17 (2)

pthread_once is just not there.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]