* 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