Linking against library in release and .exe in debug crashes in Visual studio

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 http://stackoverflow.com/questions/746298/how-do-you-build-a-debug-exe-msvcrtd-lib-against-a-release-built-lib-msvcrt-l, 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

The problem here is that the debug will use the debug version of the c runtime and the release will use the release version of the c runtime and when you try to access memory across the dll boundary it will be in the wrong run time and crash. Its all ways best to use only debug builds together (or release)

Answer 2

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?

Answer 3

For the mix of release and debug problems that earlier people have mentioned, those issues would not show up until the wrong runtime library tried to de-allocate. I think what you are running into is that VS 2008 has iterator debugging enabled by default, so your lib and your exe are referring to different implementations of std::vector. You will want to add _HAS_ITERATOR_DEBUGGING=0 to your preprocessor settings. Then you will start hitting the problem of different heaps for the different runtimes. In the past we have had different rules and policies to avoid this, but now we just rely on a consistent build environment - don't mix and match.