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 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.

Solution 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?

Solution 2

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.

Solution 3

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)

Comments

[Edison Gustavo Muenz]

Yes that is my problem. However, how do lib developers that release their libs compiled as 'release' do to make them 'linkable' with a program running in debug mode? Do they follow these 'strict rules' you are saying?

[gbjbaanb]

are you using the static or dynamic CRT in our lib? If you want it to be completely portable, then use the static version as all CRT calls will be embedded into the lib then. Alternatively build your exe with the release CRT. I'm not sure there are many commercial static libs, people tend to supply dlls instead.

[Fernando N.]

where do you see any dynamic allocation?

[TripleS]

Following those specific rules, Is there could be any problem with different packing in debug - release modes?

[gbjbaanb]

@TripleS yes, but only if the structures are exposed outside the dll - which will almost certainly happen in practice. Don't change the packing leave them at default - it almost never makes sense to change from default.