<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation" href="https://bugs.freedesktop.org/show_bug.cgi?id=98048#c18">Comment # 18</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - libpthread-stubs must NOT provide symbols which depend on actual implementation" href="https://bugs.freedesktop.org/show_bug.cgi?id=98048">bug 98048</a> from <a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> Emil Velikov</a> <pre>Just saw your IRC poke, barring the handles. For the future - myself xexaxo, Rob robclark, and Ian idr. $ nm -CD --defined-only /usr/lib/libpthread-2.24.so | grep pthread_mutexattr_settype 000000000000bc30 T __pthread_mutexattr_settype 000000000000bc30 T pthread_mutexattr_settype [emil@arch-x1c3 mesa]$ nm -CD --defined-only /usr/lib/libc-2.24.so | grep pthread_mutexattr_settype | wc -l 0 Dropping the symbols will fix the "brokenness" since then the pthread-stubs will expand to a plain .pc file (no DSO), thus only libc/libpthread will be used. In practise all Linux distros will end up like ^^ since glibc and musl have provided the fa6db2f9c01~1 symbols for quite a few years. IIRC even latest Solaris does so. Thinking about the days, where libc did not provide the stubs and fa6db2f9c01 were not around - things were bound to break in an identical way. For example: Foo uses the fa6db2f9c01~1 pthreads API and links against pthreads-stubs. Be that directly or indirectly by/in one of its dependencies. Foo uses the stubs and then dlopens libbar2. The latter links against libpthread and the weak pthread-stubs symbols are overwritten. At this point we'll get issues similar to the one described. If we are to fix this: a) in foo - this means that one will need to link against full blown pthreads, even though it does not want/need it. That is because foo cannot know if the modules that it is going to use will pull pthreads, pthread-stubs or neither. b) in pthread-stubs - one will end up re-implementing most of glibc libc<>libpthread heuristics. So if anything I'd consider making things blindingly obvious that if runtime X doesn't provide pthread-stubs behaviour things can break at any point. Thus suggest a pthreads link for the very odd platform. /me goes to add error messages for libdrm/mesa if $pkg-config --libs pthread-stubs is non-null</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>