On 1:59 PM, Nelson, Erik - 2 wrote:
Boost.Thread has some rather serious issues on mingw. [...] I intend to look at these tomorrow. I haven't touched mingw in a while, and the recent mingw releases appear to have changed the way things work. I have not encountered any problems with static linking with MSVC, but I will see if I can reproduce the problems.
Anthony Hey Anthony. I've been unable to produce the MSVC problem, too. I think the issue is just with mingw.
I think the current wave/testwave trunk regression test for MinGW illustrates thread's linking issues (or one of them). It links with static libraries. The link fails looking for two undefined symbols: _imp___ZN5boost6detail12get_tss_dataEPKv _imp___ZN5boost6detail12set_tss_dataEPKvNS_10shared_ptrINS0_20tss_cleanup_functionEEEPvb These are the dllimport symbols for: boost::detail::get_tss_data(void const*) boost::detail::set_tss_data(void const*, boost::shared_ptr<boost::detail::tss_cleanup_function>, void*, bool) The errors are coming from libboost_wave, not the (test) source. So that library appears to have been compiled incorrectly. The test was compiled with: -DBOOST_SYSTEM_STATIC_LINK=1 -DBOOST_THREAD_USE_LIB=1 -DDATE_TIME_INLINE But the library was compiled with just -DBOOST_ALL_NO_LIB=1 And these two export symbols are in thread's static library (but not with dllimport's 'imp' prefix). Should all static libraries be built with -DBOOST_THREAD_USE_LIB, or should BOOST_ALL_NO_LIB or other flags automatically define it? (Or is this specific test build configured wrong?)
We use Boost.Thread 1.43 on MSVC 2008 and haven't seen any issues.
[...]