Link errors with MSVC 9 application using Boost date_time on DEBUG build
I have a very simple app that I'm trying to link with the Boost date_time library. It links and runs fine with I build against the RELEASE configuration. But I get the following link errors when when I use the DEBUG configuration: 2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z) 2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z) It is linking against "libboost_date_time-vc90-mt-sgdp-1_38.lib". Using undname, I can see that the library is using the __thiscall convention instead of __cdecl. Is this a problem in my configuration for building the Boost date_time library, or a problem in my app's build configuration? Thanks in advance for any help! Tom Aylesworth Reality Mobile LLC
AMDG Tom Aylesworth wrote:
I have a very simple app that I'm trying to link with the Boost date_time library. It links and runs fine with I build against the RELEASE configuration. But I get the following link errors when when I use the DEBUG configuration:
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
It is linking against "libboost_date_time-vc90-mt-sgdp-1_38.lib". Using undname, I can see that the library is using the __thiscall convention instead of __cdecl. Is this a problem in my configuration for building the Boost date_time library, or a problem in my app's build configuration?
I believe that __thiscall is the default for member functions. You need to either change your app's build configuration to use the default or force the date_time library to be built with __cdecl. In Christ, Steven Watanabe
Thanks for the fast response, Steven. However, if the problem was in the way my test application or the library was being built, my program should fail the same way in the RELEASE configuration. With a little more testing, I was able to build the DEBUG configuration if I set the Optimization flag for my test application to O2. In this case, it was still building against the debug version of the boost library (libboost_date_time-vc90-mt-sgdp-1_38.lib) and yet it linked and ran correctly. I suspect this may be related to the bug you mention in this note: http://www.nabble.com/Re:-can't-build-threads-on-msvc-7.1-p21504140.html But even if it is, I don't know how to work around that in my case. Any ideas? Thanks again, Tom -----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Steven Watanabe Sent: Friday, March 13, 2009 17:10 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Link errors with MSVC 9 application using Boost date_time on DEBUG build AMDG Tom Aylesworth wrote:
I have a very simple app that I'm trying to link with the Boost date_time library. It links and runs fine with I build against the RELEASE configuration. But I get the following link errors when when I use the DEBUG configuration:
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
It is linking against "libboost_date_time-vc90-mt-sgdp-1_38.lib". Using undname, I can see that the library is using the __thiscall convention instead of __cdecl. Is this a problem in my configuration for building the Boost date_time library, or a problem in my app's build configuration?
I believe that __thiscall is the default for member functions. You need to either change your app's build configuration to use the default or force the date_time library to be built with __cdecl. In Christ, Steven Watanabe _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
AMDG Tom Aylesworth wrote:
Thanks for the fast response, Steven. However, if the problem was in the way my test application or the library was being built, my program should fail the same way in the RELEASE configuration.
Maybe. Can you post the two command lines?
With a little more testing, I was able to build the DEBUG configuration if I set the Optimization flag for my test application to O2. In this case, it was still building against the debug version of the boost library (libboost_date_time-vc90-mt-sgdp-1_38.lib) and yet it linked and ran correctly.
Is changing to /O2 the only change that you made?
I suspect this may be related to the bug you mention in this note:
http://www.nabble.com/Re:-can't-build-threads-on-msvc-7.1-p21504140.html
I don't think it's related. In Christ, Steven Watanabe
Steven Watanabe wrote:
Tom Aylesworth wrote:
Thanks for the fast response, Steven. However, if the problem was in the way my test application or the library was being built, my program should fail the same way in the RELEASE configuration.
Maybe. Can you post the two command lines?
With a little more testing, I was able to build the DEBUG configuration if I set the Optimization flag for my test application to O2. In this case, it was still building against the debug version of the boost library (libboost_date_time-vc90-mt-sgdp-1_38.lib) and yet it linked and ran correctly.
Is changing to /O2 the only change that you made?
Yes. Here's the full set of command line options from Visual Studio for the two configurations. The DEBUG configuration the way it should be (with no optimization): /Od /I "C:\AccuRev\Norfolk Development\Source\..\Libs\STLport-5.2.1\stlport" /I "C:\AccuRev\Norfolk Development\Source\..\Libs\boost_1_38_0" /I "IncomingSmsFilter/" /D "_DEBUG" /D "DEBUG" /D "_STLP_DEBUG" /D "_WIN32_WCE=0x501" /D "UNDER_CE" /D "WIN32_PLATFORM_WFSP" /D "WINCE" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "ARMV4I" /D "_UNICODE" /D "UNICODE" /D "_WIN32" /D "WIN32" /D "SMARTPHONE2003_UI_MODEL" /D "_CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA" /D "_WINDLL" /D "_ATL_STATIC_REGISTRY" /Gm /EHsc /MTd /fp:fast /GR /Yu"stdafx.h" /Fp"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/Client.pch" /Fo"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/" /Fd"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/vc80.pdb" /W3 /nologo /c /Zi /TP /wd4290 The DEBUG configuration with optimization turned on: /O2 /I "C:\AccuRev\Norfolk Development\Source\..\Libs\STLport-5.2.1\stlport" /I "C:\AccuRev\Norfolk Development\Source\..\Libs\boost_1_38_0" /I "IncomingSmsFilter/" /D "_DEBUG" /D "DEBUG" /D "_STLP_DEBUG" /D "_WIN32_WCE=0x501" /D "UNDER_CE" /D "WIN32_PLATFORM_WFSP" /D "WINCE" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "ARMV4I" /D "_UNICODE" /D "UNICODE" /D "_WIN32" /D "WIN32" /D "SMARTPHONE2003_UI_MODEL" /D "_CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA" /D "_WINDLL" /D "_ATL_STATIC_REGISTRY" /Gm /EHsc /MTd /fp:fast /GR /Yu"stdafx.h" /Fp"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/Client.pch" /Fo"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/" /Fd"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/vc80.pdb" /W3 /nologo /c /Zi /TP /wd4290 The first configuration (no optimization) fails with the linker errors mentioned previously. The second (with optimization) links and runs correctly. Note that the only difference is the optimization flag. Thanks again for the help! Tom
Steven Watanabe wrote:
Tom Aylesworth wrote:
I have a very simple app that I'm trying to link with the Boost date_time library. It links and runs fine with I build against the RELEASE configuration. But I get the following link errors when when I use the DEBUG configuration:
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_long_string(void)const " (?as_long_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
2>TimeUtil.obj : error LNK2019: unresolved external symbol "public: char const * __cdecl boost::gregorian::greg_month::as_short_string(void)const " (?as_short_string@greg_month@gregorian@boost@@QBAPBDXZ) referenced in function "public: static class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > & __cdecl boost::date_time::month_formatter<class boost::gregorian::greg_month,class boost::date_time::iso_extended_format<wchar_t>,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream<wchar_t,class stlpd_std::char_traits<wchar_t> > &)" (?format_month@?$month_formatter@Vgreg_month@gregorian@boost@@V?$iso_extended_format@_W@date_time@3@_W@date_time@boost@@SAAAV?$basic_ostream@_WV?$char_traits@_W@stlpd_std@@@stlpd_std@@ABVgreg_month@gregorian@3@AAV45@@Z)
It is linking against "libboost_date_time-vc90-mt-sgdp-1_38.lib". Using undname, I can see that the library is using the __thiscall convention instead of __cdecl. Is this a problem in my configuration for building the Boost date_time library, or a problem in my app's build configuration?
I believe that __thiscall is the default for member functions. You need to either change your app's build configuration to use the default or force the date_time library to be built with __cdecl.
Some further experimentation has convinced me that you are correct. And I'm having the same problem trying to link with the Boost thread library as I am with the Boost date_time library. However, I can't figure out why my application is trying to use __cdecl convention or how to force it to use __thiscall. According to the MSDN documentation, __thiscall is the default for member functions. And I can see that the boost libraries are correctly using __thiscall. The compiler flags I am using are the defaults, and none should be affecting the calling conventions as far as I can tell. Here are the compiler options: /Od /I "C:\AccuRev\Norfolk Development\Source\..\Libs\STLport-5.2.1\stlport" /I "C:\AccuRev\Norfolk Development\Source\..\Libs\boost_1_38_0" /I "IncomingSmsFilter/" /D "_DEBUG" /D "DEBUG" /D "_STLP_DEBUG" /D "_WIN32_WCE=0x501" /D "UNDER_CE" /D "WIN32_PLATFORM_WFSP" /D "WINCE" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "ARMV4I" /D "_UNICODE" /D "UNICODE" /D "_WIN32" /D "WIN32" /D "SMARTPHONE2003_UI_MODEL" /D "_CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA" /D "_WINDLL" /D "_ATL_STATIC_REGISTRY" /Gm /EHsc /MTd /fp:fast /GR /Yu"stdafx.h" /Fp"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/Client.pch" /Fo"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/" /Fd"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/vc80.pdb" /W3 /nologo /c /Zi /TP /wd4290 Thanks. Any help is greatly appreciated! Tom
AMDG Tom Aylesworth wrote:
Some further experimentation has convinced me that you are correct. And I'm having the same problem trying to link with the Boost thread library as I am with the Boost date_time library.
However, I can't figure out why my application is trying to use __cdecl convention or how to force it to use __thiscall. According to the MSDN documentation, __thiscall is the default for member functions. And I can see that the boost libraries are correctly using __thiscall.
The compiler flags I am using are the defaults, and none should be affecting the calling conventions as far as I can tell. Here are the compiler options:
/Od /I "C:\AccuRev\Norfolk Development\Source\..\Libs\STLport-5.2.1\stlport" /I "C:\AccuRev\Norfolk Development\Source\..\Libs\boost_1_38_0" /I "IncomingSmsFilter/" /D "_DEBUG" /D "DEBUG" /D "_STLP_DEBUG" /D "_WIN32_WCE=0x501" /D "UNDER_CE" /D "WIN32_PLATFORM_WFSP" /D "WINCE" /D "_WINDOWS" /D "ARM" /D "_ARM_" /D "ARMV4I" /D "_UNICODE" /D "UNICODE" /D "_WIN32" /D "WIN32" /D "SMARTPHONE2003_UI_MODEL" /D "_CE_ALLOW_SINGLE_THREADED_OBJECTS_IN_MTA" /D "_WINDLL" /D "_ATL_STATIC_REGISTRY" /Gm /EHsc /MTd /fp:fast /GR /Yu"stdafx.h" /Fp"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/Client.pch" /Fo"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/" /Fd"Windows Mobile 5.0 Smartphone SDK (ARMV4I)\Debug/vc80.pdb" /W3 /nologo /c /Zi /TP /wd4290
Thanks. Any help is greatly appreciated!
I have no idea. Here's some diagnostic code: class check_calling_convention { void f(); }; void __thiscall check_calling_convention::f() {} If this compiles when placed at the beginning of the source file, then there's a problem in the compiler options. If it fails only at some later point, then some header is doing some kind of magic, and you'll need to figure out which one it is. In Christ, Steven Watanabe
participants (2)
-
Steven Watanabe -
Tom Aylesworth