Re: Undefined use of weak symbols in gnulib

2021-04-26 Thread 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.

Re: Undefined use of weak symbols in gnulib

2021-04-26 Thread 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

[PATCH] gnulib-tool: port better to current Autoconf

2021-04-26 Thread Paul Eggert
* doc/gnulib-tool.texi (Initial import): Don’t mention AC_PROG_CC_STDC as it’s deprecated in current Autoconf. * gnulib-tool (func_done_dir): Suggest replacing AC_PROG_CC_STDC and AC_PROG_CC_C99, as per current Autoconf. --- ChangeLog| 8 doc/gnulib-tool.texi | 11 ---

Undefined use of weak symbols in gnulib

2021-04-26 Thread Florian Weimer
lib/glthread/lock.h has this: | /* The way to test at runtime whether libpthread is present is to test |whether a function pointer's value, such as &pthread_mutex_init, is |non-NULL. However, some versions of GCC have a bug through which, in |PIC mode, &foo != NULL always evaluates to