<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c15">Comment # 15</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 <span class="vcard"><a class="email" href="mailto:emil.l.velikov@gmail.com" title="Emil Velikov <emil.l.velikov@gmail.com>"> <span class="fn">Emil Velikov</span></a>
</span></b>
        <pre>(In reply to Rob Clark from <a href="show_bug.cgi?id=98048#c13">comment #13</a>)
<span class="quote">> (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.
> </span >
Yes, we can add a lot more error checking/alike and make things more robust. By
then they won't be plain stubs though ;-)

If we consider that mesa (and maybe others) do zero error checking for
pthread_mutexattr_* and pthread_mutex_init and others, it smells like accident
waiting to happen. Guess we should fix that, one of these days as well.

<span class="quote">> 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?</span >
Pretty much. If you/Ben rebuild pthreads-stubs (and packages which depend on
it) you'll see issues similar to the ones Ian reported.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
          <li>You are the QA Contact for the bug.</li>
      </ul>
    </body>
</html>