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

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