views:

224

answers:

2

I have a project compiled using __cdecl calling convention (msvc2010) and I compiled boost using the same compiler using the default settings.

The project linked with boost but I at runtime I got an assert message like this: File: ...\boost\boost\program_options\detail\parsers.hpp Line: 79

Run-Time Check Failure #0 - The value of ESP was not properly saved across a function call. This is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

There are the following questions:

  • what calling convention does boost build with by default on Windows (msvc2010)
  • how to I compile boost with __cdecl calling convention
  • why boost wasn't able to prevent linking with code with different calling conventions? I understood that boost has really smart library auto-inclusion code.

Update #1

It looks that boost does compile and link with proper calling convention, still at runtime I get the above problem. I did a sample application using the same code and it works but in my application it fails. The only difference could be from project configuration or includes/stdafx.h

+1  A: 

As far as I know there's not way to make C++ use cdecl calling conventions (see MSDN Calling Convention). The C++ method calling is just different from C. The only opportunity that you have to use one of the C calling conventions is for functions, which include class static functions in C++. If you know that's the case you can try forcing the option when building by adding the option during the build:

bjam cxxflags=/Gd ...

(see BBv2 Builtin features)

Or to make it "permanent" set up a user-config.jam with your compiler and add it to the build options for all BBv2 msvc builds (see BBv2 Configuration and related docs). As for you other questions:

  1. Boost uses the default calling convention MSVC uses, except for cases where it overrides it at the code level. I don't know where those are as they are library specific. So you'd have to search the code for the "__*" code decorators.
  2. See above for partial answer.
  3. Detection; there are two reasons: There is a limit to how many different options we can reasonably detect for for building as it's an exponential growth of different possible variations so we limit it to the most important cases. And in the case of calling convention, it's not actually possible since it's something that can be changed on a per function basis.
GrafikRobot
A: 

I found the cause of the problem inside one of the shared property files: <StructMemberAlignment>4Bytes</StructMemberAlignment>

If I remove it the code will work. Still, I'm not sure why this is happening and how could I solve it without removing the above code (that was required by another library).

I added another question regarding boost and structure member alignment.

Sorin Sbarnea