I can't link Boost Thread library
I tried to use the Boost Thread library with Windows and VC++ 7.1 (.NET IDE)
and STLPort-4.6.2 but I didn't succeed. I tried with:
- boost jam
- generating a DLL from a new project directly in the IDE (dynamic linking)
- including the sources in the exe project (static linking)
The static linking gives me an error with "tss_cleanup_implemented", which
is not accidental but wanted by the developers ("This function's sole purpose
is to cause a link error..."), while the dinamyc linking gives me another
error:
"TestPalantirWrapper error LNK2019: unresolved external symbol "public: __thiscall
boost::thread::thread(class boost::function0
The static linking gives me an error with "tss_cleanup_implemented", which is not accidental but wanted by the developers ("This function's sole purpose is to cause a link error..."), while the dinamyc linking gives me another error:
"TestPalantirWrapper error LNK2019: unresolved external symbol "public: __thiscall boost::thread::thread(class boost::function0
const &)" (??0thread@boost@@QAE@ABV?$function0@XV?$allocator@Vfunction_base@boost@@@_STL@@@1@@Z) referenced in function _main"
You may need to define __STL_DEBUG to get it to link with a debug library build (bjam debug builds turn that on automatically for msvc+STLport).
(it was th thread.cpp example). A strange thing happens with dynamic linking: using "BOOST_LIB_DIAGNOSTIC", I get the message
"Linking to lib file: libboost_thread-vc71-mt-sgdp-1_32.lib" ,
Looks like you are trying to use a static msvc runtime: you will need to use a dll runtime (under the code generation options) to use a Boost lib as a dll.
beginning with "lib", and not the dynamic one (without "lib"). In particular, generating a DLL from the IDE from the the source files:
(1) requires the library libboost_thread-vc71-mt-sgdp-1_32.lib (why?) (2) doesn't generate an import library (".lib") but only the .dll
(2) Will happen if there is nothing to export from the dll: and that will happen if you are using a static runtime (we really should have fixed this to make it a compiler error, but that's another issue). HTH, John.
participants (2)
-
Ivan Makale
-
John Maddock