https://svn.boost.org/trac10/ticket/5170 <p> The thread_proxy and tls_destructor functions in libs/thread/src/pthread/thread.cpp have external linkage (the symbols are exported in the final library). However, these functions are only intended for use inside this compilation unit. Similar functions in once.cpp also have unintended external linkage, and potentially others in other areas of boost. A consequence of these symbols being visible is that it's hard to use two different versions of boost.Thread in the same binary, even when one of the versions of boost has been wrapped in a namespace to avoid name collisions. The name collisions still occur for thread_proxy, tls_destructor, and the others because they are declared as extern "C", so their names are not mangled. </p> <p> It may seem unusual to attempt to use two different versions of boost in the same program, but it is a scenario our customers are running into more and more often and I'd like to give some explanation of why it happens. As more development projects start to use boost, more libraries start to link against it. A program that attempts to use multiple of those libraries won't work if they use different versions of boost. When one or more of these libraries is available in binary form and not source form, it is difficult to ensure the boost versions match. As a result, our customers attempt to version boost's symbols themselves for the boost version they use by compiling a version of boost wrapped in a namespace. Unfortunately, symbols from extern "C" functions are not versioned. </p> <p> The thread_proxy, tls_destructor, etc., functions in question need to be declared as extern "C" since they are passed as callbacks into the pthreads library, and the calling conventions for C and C++ may differ on some platforms (<a class="ext-link" href="http://lists.boost.org/Archives/boost/2011/01/175910.php"><span class="icon">​</span>http://lists.boost.org/Archives/boost/2011/01/175910.php</a>). </p> <p> Prior to revision 40424, these functions were declared as static. However, in revision 40424 the static specifier was removed and they were put inside an unnamed namespace. However, despite the claim at <a class="ext-link" href="http://stackoverflow.com/questions/2594178/why-do-you-need-extern-c-for-c-callbacks-to-c-functions"><span class="icon">​</span>http://stackoverflow.com/questions/2594178/why-do-you-need-extern-c-for-c-callbacks-to-c-functions</a> that "[the extern "C" function] is in an unnamed namespace, and not accessible outside the translation unit.", these functions do have external linkage, at least on g++ Linux systems. The bug at <a class="ext-link" href="http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409"><span class="icon">​</span>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28409</a> mentions that "extern C should make the function have external linkage in the object file. Namespaces have no impact on extern "C" functions, except from the point of view of lexical scoping", and this can be confirmed by looking for thread_proxy in the output of nm -D. </p> <p> It it possible to please add back the static specifier to the extern "C" functions in question? Attached is a patch file showing the proposed changes. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/5170 Trac 1.4.3 Luke Moore <luke.moore@…> Tue, 08 Feb 2011 17:31:00 GMT https://svn.boost.org/trac10/ticket/5170 https://svn.boost.org/trac10/ticket/5170 <ul> <li><strong>attachment</strong> → <span class="trac-field-new">thread.patch</span> </li> </ul> <p> Patch to add static specifier to extern "C" functions </p> Ticket viboes Tue, 10 May 2011 21:52:03 GMT https://svn.boost.org/trac10/ticket/5170#comment:1 https://svn.boost.org/trac10/ticket/5170#comment:1 <ul> <li><strong>type</strong> <span class="trac-field-old">Bugs</span> → <span class="trac-field-new">Feature Requests</span> </li> </ul> <p> I would not consider this as a bug on Boost.Thread, but a feature requests, as you are using the library in context that are outside of what the author designed it for. Please be free to change if you don't agree. </p> Ticket luke.moore@… Wed, 11 May 2011 14:28:46 GMT https://svn.boost.org/trac10/ticket/5170#comment:4 https://svn.boost.org/trac10/ticket/5170#comment:4 <ul> <li><strong>status</strong> <span class="trac-field-old">new</span> → <span class="trac-field-new">closed</span> </li> <li><strong>resolution</strong> → <span class="trac-field-new">fixed</span> </li> </ul> <p> I have taken the liberty of putting in a fix. This defect is extremely serious, very difficult to debug and occurs frequently with the use of third-party shared libraries. </p> <p> I have modified pthread/thread.cpp to make thread_proxy and tls_destructor internal linkage. I have tested that this resolves the issue. </p> Ticket luke.moore@… Wed, 25 May 2011 15:10:11 GMT