Link errors using Boost & STLPort with VC8
Hi all, I read about the following discussion when I encountered a similar issue (using -MTd -D_STLP_DEBUG=1 on the command line) and googled: John Maddock wrote:
Jason Ivey wrote:
1>LINK : fatal error LNK1104: cannot open file 'stlportstld_x.5.1.lib'
The problem is that all of the stlport libraries are named stlportstld.5.1.lib or similar. I did try to just rename the library to make it match but, of course, I got a boat load of unresolved external linker errors pointing to names such as "stlpdx_std::basic_string." Looking at a dumpbin output of the actual regex library it is linking against, libboost_regex-vc80-mt-sgdp-1_34_1.lib, I found linker directives of the form:
Not sure, but I believe the debug versions of Boost lib's built against STLPort are built with __STL_DEBUG defined, so you will need to do likewise when building your application. Also don't forget that Boost.Regex is "Just a bunch of sources" so you could turn auto-linking off (define BOOST_REGEX_NO_LIB or BOOST_ALL_NO_LIB) and link against your own build of the regex sources (just build all of libs/regex/src/*.cpp into a static lib).
It seems to me the reason for the failure is that there are some DLL-related conflicts. In _detect_dll_or_lib.h: # if defined (_STLP_RUNTIME_DLL) # if !defined (_STLP_USE_STATIC_LIB) # if !defined (_STLP_USE_DYNAMIC_LIB) # define _STLP_USE_DYNAMIC_LIB # endif # else /* The user is forcing use of STLport as a dynamic library. We signal * it so that the STLport namespace will be modify to report such a * combination and force the user to link with the rebuilt STLport * library. */ # define _STLP_USING_CROSS_NATIVE_RUNTIME_LIB # endif # else # if !defined(_STLP_USE_DYNAMIC_LIB) # if !defined (_STLP_USE_STATIC_LIB) # define _STLP_USE_STATIC_LIB # endif # else /* Idem previous remark but the user forces use of the static native * runtime. */ # define _STLP_USING_CROSS_NATIVE_RUNTIME_LIB # endif # endif Is it possible that such a conflict exists when libboost_regex-vc71-mt-sgdp-1_34_1.lib (my case) or libboost_regex-vc80-mt-sgdp-1_34_1.lib (OP's case) is being built? And, according to your suggestion, if I manually build libboost_regex-vc71-mt-sgdp-1_34_1.lib with cl /MTd /D_STLP_DEBUG=1 *.cpp followed by lib /out:libboost_regex-vc71-mt-sgdp-1_34_1.lib *.obj Everything is fine. Another thing to notice here is that unlike the case of STLport 4.6.2, files like boost*p-1_34_1.lib and boost*p-1_34_1.dll are NOT created. Is it related? BTW, without -D__STL_DEBUG=1 or -D_STLP_DEBUG=1 Boost will complain "STLPort debug versions are built with /D_STLP_DEBUG=1" and "Build options aren't compatible with pre-built libraries", so this should not be an issue. Comments? Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
On 19/09/2007, Yongwei Wu wrote:
Hi all,
I read about the following discussion when I encountered a similar issue (using -MTd -D_STLP_DEBUG=1 on the command line) and googled:
John Maddock wrote:
Jason Ivey wrote:
1>LINK : fatal error LNK1104: cannot open file 'stlportstld_x.5.1.lib'
The problem is that all of the stlport libraries are named stlportstld.5.1.lib or similar. I did try to just rename the library to make it match but, of course, I got a boat load of unresolved external linker errors pointing to names such as "stlpdx_std::basic_string." Looking at a dumpbin output of the actual regex library it is linking against, libboost_regex-vc80-mt-sgdp-1_34_1.lib, I found linker directives of the form:
Not sure, but I believe the debug versions of Boost lib's built against STLPort are built with __STL_DEBUG defined, so you will need to do likewise when building your application. Also don't forget that Boost.Regex is "Just a bunch of sources" so you could turn auto-linking off (define BOOST_REGEX_NO_LIB or BOOST_ALL_NO_LIB) and link against your own build of the regex sources (just build all of libs/regex/src/*.cpp into a static lib).
It seems to me the reason for the failure is that there are some DLL-related conflicts. In _detect_dll_or_lib.h:
# if defined (_STLP_RUNTIME_DLL) # if !defined (_STLP_USE_STATIC_LIB) # if !defined (_STLP_USE_DYNAMIC_LIB) # define _STLP_USE_DYNAMIC_LIB # endif # else /* The user is forcing use of STLport as a dynamic library. We signal * it so that the STLport namespace will be modify to report such a * combination and force the user to link with the rebuilt STLport * library. */ # define _STLP_USING_CROSS_NATIVE_RUNTIME_LIB # endif # else # if !defined(_STLP_USE_DYNAMIC_LIB) # if !defined (_STLP_USE_STATIC_LIB) # define _STLP_USE_STATIC_LIB # endif # else /* Idem previous remark but the user forces use of the static native * runtime. */ # define _STLP_USING_CROSS_NATIVE_RUNTIME_LIB # endif # endif
Is it possible that such a conflict exists when libboost_regex-vc71-mt-sgdp-1_34_1.lib (my case) or libboost_regex-vc80-mt-sgdp-1_34_1.lib (OP's case) is being built?
After testing with STLport 4.6.2, I am more inclined to believe this is the reason. When I built the same simple program with STLport 4.6.2 again (with /MTd /D_STL_DEBUG=1), I saw these messages (with /link /verbose): Starting pass 1 Processed /DEFAULTLIB:stlport_vc71_stldebug_static.lib Processed /DEFAULTLIB:libcpmtd Processed /DEFAULTLIB:libboost_regex-vc71-mt-sgdp-1_34_1.lib ... Loaded libboost_regex-vc71-mt-sgdp-1_34_1.lib(instances.obj) Processed /DEFAULTLIB:stlport_vc71_stldebug.lib Searching C:\Libraries\STLport-4.6.2\lib\stlport_vc71_stldebug.lib: Found "__declspec(dllimport) public: __thiscall _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >::~basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >(void)" (__imp_??1?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@QAE@XZ) Referenced in libboost_regex-vc71-mt-sgdp-1_34_1.lib(instances.obj) Referenced in libboost_regex-vc71-mt-sgdp-1_34_1.lib(regex.obj) Referenced in libboost_regex-vc71-mt-sgdp-1_34_1.lib(w32_regex_traits.obj) Loaded stlport_vc71_stldebug.lib(stlport_vc71_stldebug46.dll) stlport_vc71_stldebug.lib(stlport_vc71_stldebug46.dll) : error LNK2005: "public: __thiscall _STL::basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char>
::~basic_string<char,class _STL::char_traits<char>,class _STL::allocator<char> >(void)" (??1?$basic_string@DV?$char_traits@D@_STL@@V?$allocator@D@2@@_STL@@QAE@XZ) already defined in test.obj ...
I see no reason why the DLL build of STLport (stlport_vc71_stldebug. lib) should be referenced in a static build of Boost.Regex (libboost_regex-vc71-mt-sgdp-1_34_1.lib). I am not familiar with bjam enough to investigate further. Any help is appreciated. Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
Yongwei Wu wrote:
I see no reason why the DLL build of STLport (stlport_vc71_stldebug. lib) should be referenced in a static build of Boost.Regex (libboost_regex-vc71-mt-sgdp-1_34_1.lib).
Or no reason why not either: you can use the STLport dll as long as you are using a dll runtime. You can likewise use either the static or dll regex lib with a dll runtime.
I am not familiar with bjam enough to investigate further. Any help is appreciated.
It looks like stlport.jam is forcing _STLP_USE_DYNAMIC_LIB on for some reason, I'll post a message on the Boost.Build list about this, since I don't understand BBv2's internals either ! John.
On 19/09/2007, John Maddock wrote:
Yongwei Wu wrote:
I see no reason why the DLL build of STLport (stlport_vc71_stldebug. lib) should be referenced in a static build of Boost.Regex (libboost_regex-vc71-mt-sgdp-1_34_1.lib).
Or no reason why not either: you can use the STLport dll as long as you are using a dll runtime. You can likewise use either the static or dll regex lib with a dll runtime.
The suffix "-s" suggests it should be linked "statically to the C++ standard library and compiler runtime support libraries". That is reason why it is selected automatically by "/MTd".
I am not familiar with bjam enough to investigate further. Any help is appreciated.
It looks like stlport.jam is forcing _STLP_USE_DYNAMIC_LIB on for some reason, I'll post a message on the Boost.Build list about this, since I don't understand BBv2's internals either !
Thanks! Best regards, Yongwei -- Wu Yongwei URL: http://wyw.dcweb.cn/
participants (2)
-
John Maddock -
Yongwei Wu