<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#c13">Comment # 13</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:robclark@freedesktop.org" title="Rob Clark <robclark@freedesktop.org>"> Rob Clark</a> <pre>(In reply to Emil Velikov from <a href="show_bug.cgi?id=98048#c11">comment #11</a>) > (In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c6">comment #6</a>) > > so in that regard, stubbing pthread_mutexattr_settype() is > > completely legit. > > > Not really :-\ AFAICT setting/changing the mutexattr implies that one > requires actual locking. Well, to be super-anal, pthreads-stub should perhaps flag an error or assert or something for non-recursive mutex if recursively acquired. But I guess no one has cared about that so far. It doesn't help that the default mutex type can be (but doesn't have to be) recursive. But I don't see how setting mutexattr implies that you require locking in a single-threaded environment any more than pthread_mutex_lock() does. So I still think stubbing the mutexattr fxns is not wrong.. but I guess there is an unfortunate interaction with how pthread syms that aren't in libc get resolved? Maybe reverting the stubs is more convenient than fixing glibc if we can't figure out how to get the symbols from libpthread before pthread-stubs. That said, all I have of pthreads-stubs in my filesystem is the .pc file, which I guess explains why I am not seeing this issue?</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>