<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#c21">Comment # 21</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:psychon@znc.in" title="Uli Schlachter <psychon@znc.in>"> Uli Schlachter</a> <pre>(In reply to Emil Velikov from <a href="show_bug.cgi?id=98048#c18">comment #18</a>) > 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. Ah, dlopen(). Ok, that does indeed explain the problems that everyone is seeing. However, my memory warns me about dlopen()ing libpthread and random google results say that it doesn't work too well, e.g. <a href="https://freetz.org/ticket/819">https://freetz.org/ticket/819</a> and <a href="https://sourceware.org/bugzilla/show_bug.cgi?id=16628">https://sourceware.org/bugzilla/show_bug.cgi?id=16628</a>. However, only on Linux is this actually an issue with the patch that should be reverted. On other patches, other things will break. Since you seem to be trying to fix this in pthread-stubs (thanks for those patches!), I'll stop complaining about dlopen()ing libpthreads now.</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>