Using debug/release versions DLL in C++

I am writing an C+开发者_JAVA百科+ application that could be compiled under Linux (gcc 4.3) and Windows (MS VS08 Express).

My application uses third-party libraries,

On Linux , they are compiled as shared libraries, while on Windows, there are two versions "Debug" and "Release".

I know that debug version provides extra support for debugging ( just like using -ggdb option in linux gcc, right? )

But I found that if my application is in debug version , the libraries must also be in debug version, otherwise the application will crash.

Why is there such a limit? It seems that there are no such limits in the linux world

Thank you very much!

The Debug configuration of your program is compiled with full symbolic debug information and no optimization. Optimization complicates debugging, because the relationship between source code and generated instructions is more complex.

The Release configuration of your program contains no symbolic debug information and is fully optimized. Debug information can be generated in PDB Files (C++) depending on the compiler options used. Creating PDB files can be very useful if you later need to debug your release version.

Debug vs Release

It is also possible to debug your release build with the compiler flags.

Debugging Release Builds

• Heap Layout - Guard Bytes to prevent overwriting
• Compilation - Removing Assert/Debug Info
• Pointer Support - Buffers around pointers to prevent seg faults
• Optimization - Inline Functions

Common Problems When Creating Release Builds

To elaborate on Martin Tornwall. The various libraries linked when in Debug or Release

• LIBCPMT.LIB, Multithreaded, static link, /MT, _MT

• LIBCPMTD.LIB, Multithreaded, static link, /MTd, _DEBUG, _MT

CRT Libraries

Most likely, the Release and Debug versions are linked against different versions of the C++ Runtime library. Usually, a Debug build links against the "Multithreaded Debug DLL" runtime, whereas a Release build will generally link against "Multithreaded DLL". Loading DLLs whose runtime libraries are mismatched with that of the application will often lead to mysterious crashes.

You could try verifying that all your DLLs build against the same runtime library as your application, regardless of which configuration (Debug or Release) is active. Whether or not this is desirable is another question entirely.

The ability to choose which runtime library to link with enables the application developer to select the best feature set given her application's requirements. For example, a single-threaded application might incur performance penalties as a result of unnecessary thread synchronization if it is linked with a runtime library that is designed with thread safety in mind. Likewise, the consequences of linking a multi-threaded application against a single-threaded runtime could potentially be disastrous.

While I never intentionally link libraries that were built with different compiler settings, there isn't much point in doing so, I only know of the STL classes in the Dinkumware implementation (the one MSFT uses) to cause this problem.

They support a feature called 'iterator debugging' which is turned on by default in the Debug configuration. This adds members to the classes to aid the diagnostic code. Making them larger. This goes bad when you create the object in a chunk of code that was compiled with one setting and pass it to code that was compiled with the opposite setting. You can turn this off by setting the _HAS_ITERATOR_DEBUGGING macro to 0. Which is rather a major loss, the feature is excellent to diagnose mistakes in the way you use STL classes.

Passing objects or pointers between different libraries is always a problem if you don't carefully control the compile settings. Mixing and matching the CRT version and flavor gets you in trouble when you do so. This normally generates a warning from the linker, not sure what you did to not see it. There won't be one if the code lives in a DLL.