[Thread] Win32 TLS problem with dynamic libraries
Hello, I need to build a shared plugin library with Boost libraries linked statically into it. As many may know, there's a problem with having a .tls section in Win32 dynamic libraries which are to be loaded via LoadLibrary, but Boost.Thread insists on having one. Assuming that I can guarantee that no Boost.Thread functions are called from non-Boost.Thread threads, it shouldn't be needed. Apart from patching the Boost.Thread sources, or the resulting binaries, what's the best way of eliminating it? I assume that I need to eliminate tss_pe.cpp from linkage, but I don't seem to be able to. Adding a namespace boost { void tss_cleanup_implemented() {} } to one of the library's sources doesn't help, as it results in a multiply defined symbol error (compiler MSVC2008 from Express edition). Any suggestions? Thank you, -- Sergey Zakharchenko
Le 25/10/12 15:07, Сергей Захарченко a écrit :
Hello,
I need to build a shared plugin library with Boost libraries linked statically into it. As many may know, there's a problem with having a .tls section in Win32 dynamic libraries which are to be loaded via LoadLibrary, but Boost.Thread insists on having one. Assuming that I can guarantee that no Boost.Thread functions are called from non-Boost.Thread threads, it shouldn't be needed. Apart from patching the Boost.Thread sources, or the resulting binaries, what's the best way of eliminating it?
I assume that I need to eliminate tss_pe.cpp from linkage, but I don't seem to be able to. Adding a
namespace boost { void tss_cleanup_implemented() {} }
to one of the library's sources doesn't help, as it results in a multiply defined symbol error (compiler MSVC2008 from Express edition).
Any suggestions? Thank you,
Hi, there are some tickets on the Trac system concerning this issue in Boost.Thread. Unfortunately I have not yet a clear vision of what needs to be done. I don't promise you anything, but I would like to have enough time to fix these issues for next release. Anthony, do you have an idea? have you the same kind of issues with your just::thread implementation? if not, why? Best, Vicente
2012/10/25 Vicente J. Botet Escriba
Le 25/10/12 15:07, Сергей Захарченко a écrit :
I assume that I need to eliminate tss_pe.cpp from linkage, but I don't seem to be able to. Adding a
namespace boost { void tss_cleanup_implemented() {} }
to one of the library's sources doesn't help, as it results in a multiply defined symbol error (compiler MSVC2008 from Express edition).
there are some tickets on the Trac system concerning this issue in Boost.Thread. Unfortunately I have not yet a clear vision of what needs to be done. I don't promise you anything, but I would like to have enough time to fix these issues for next release.
JFYI: our current solution integrated into our build system (CMake, MSVC) is: * Rename the Boost.Thread library into 'original_boost_thread'. * Add a custom target named 'patched_boost_thread' which uses dumpbin and lib utilities to delete just the tss_pe.obj object from Boost.Thread. * Add a library called boost_thread which links to 'patched_boost_thread' and contains a file named tss_pe.cpp which contains the aforementioned code (essentially it's the 'null tss cleanup implementation'). I know it's perverted (no, patching the Boost.Thread source is not an option for me), but it does exactly what seems to be the original intent: replace the tss_pe.obj with a stub. Targets which don't need plugin functionality can still link to original_boost_thread and (potentially) benefit from the automatic cleanup. Best regards, -- DoubleF
participants (3)
-
Sergey Zakharchenko -
Vicente J. Botet Escriba -
Сергей Захарченко