On Tue, 27 Apr 2021 at 17:53, Florian Weimer <fwei...@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
