Question

I’m using Visual C++ 2008 SP1. I have an app that is compiled in debug mode, but links against a library in release mode.

I’m getting a crash at the start-up of the application. To make the problem smaller, I created a simple solution with 2 projects:

• lib_release (generates a .lib, in release mode)
• exec_using_lib_release (genereates a .exe, in debug mode)

The ‘lib_release’ project is simple enough to have a simple class:

//Foo.h
#include <vector>
class Foo {
  std::vector<int> v;
  public:
  void doSomething();
};
//Foo.cpp
#include "Foo.h"
void Foo::doSomething() {}

The ‘exec_using_lib_release’ project is simple like this:

//main.cpp
#include "Foo.h"
int main() {
   Foo foo;
   foo.doSomething();
   return 0;
}

And it crashes, it’s the same problem reported by How do you build a debug .exe (MSVCRTD.lib) against a release built lib (MSVCRT.lib)?, but his answer didn’t work for me.

I get the same linker warnings, I tried the same steps, but none worked. Is there something I’m missing?

EDIT:

On the lib_release (that creates a library in release mode), I’m using Multi Threaded (/MT), and at the exec_using_lib_release, I’m using Multi Threaded Debug (/MTd). I think this is the expected way of doing it, since I want the .lib to be created without debug info. I read the document at MSDN Runtime library and those are the settings of linking against the CRT in a static way.

I don’t have ‘Common Language Runtime Support’ either.

Answer 1

You don’t have to use the same runtimes for release and debug modules (but it helps), as long as you follow very specific rules: never mix and ,match accessing the memory allocated using each runtime.

To put this more simply, if you have a routine in a dll that allocates some memory and returns it to the caller, the caller must never free it – you must create a function in the original dll that frees the memory. That way you’re safe from runtime mismatches.

If you consider that the Windows dlls are built release only (unless you have the debug version of Windows), yet you use them from your debug applications, you’ll see how this matters.

Your problem now is that you’re using a static library, there is no dll boundary anymore, and the calls in the lib are compiled using the static version of the C runtime. If your exe uses the dynamic dll version of the runtime, you’ll find that the linker is using that one instead of the one your static lib used… and you’ll get crashes.

So, you could rebuild your lib as a dll; or you could make sure they both use the same CRT library; or you could make sure they both use the same type of CRT – ie the dll version or the static version, whilst keeping debug/release differences.

At least, I think this is your problem – what are the ‘code generation, runtime library’ settings?