On Tue, 27 Apr 2021 at 17:53, Florian Weimer <fweimer@redhat.com> wrote:

> 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 true if there is a direct
> |    call to foo(...) in the same function.  To avoid this, we test the
> |    address of a function in libpthread that we don't use.  */
>

[snip]

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.  I expect the issue is
> already visible with earlier glibc versions if libpthread is
> unexpectedly present at run time.
>

Did this thread ever reach a conclusion? I'm testing a snapshot of glibc
2.34 in ubuntu and running into this issue -- bison segfaults on startup on
ppc64el. There is some talk of 'rebuilding the world' once 2.34 lands in a
distro but that might be hard because I suspect the world might be too
broken to do that (maybe it's not that bad really... but it doesn't sound
like fun).

Cheers,
mwh