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
> & __cdecl boost::date_time::month_formatter ,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream > &)" (?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
> & __cdecl boost::date_time::month_formatter ,wchar_t>::format_month(class boost::gregorian::greg_month const &,class stlpd_std::basic_ostream > &)" (?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