[Cmake] Fwd: [Insight-developers] Debug vs. RelWithDebInfo

Ian Scott ian . m . scott at stud . man . ac . uk
Mon, 29 Oct 2001 16:07:20 -0000

The difference between Debug and RelwithDebInfo is that RelwithDebInfo is
quite similar to Release mode. It produces fully optimised code, but also
builds the program database, and inserts debug line information to give a
debugger a good chance at guessing where in the code you are at any time.
When VXL was still using ordinary .dsp files, it was one of the build modes
several of us found very useful.

In my own case I use it for the following things.
-Debugging heisenbugs (bugs that are in release mode, but disappear when you
switch to the debug mode build.
-Attaching a debugger to long running programs (some of mine take a week) to
see if they have hung.
-Doing quick debugs when you aren't too fussed about the accuracy of the

I added this (after discussing it on the CMake reflector) as a separate
build mode, rather than just modifying my own CXX_FLAGS locally, because I
regularly use Release, Debug and RelwithDebugInfo builds. I do not want to
have to rebuild all of VXL 2 or 3 times a day.

I would not object if anyone added the facility in CMake to disable the two
non-standard build modes (MinSizeRel and RelwithDebInfo) since these may be
confusing to people who have just seen the standard Debug and Release modes.

Finally in response to your particular problems
1. Re the build error..
Blame microsoft for deciding to require specification of the Standard C and
C++ libraries at compile time (rather than link time)
\MD specifies using the multithread supporting, non-debug DLL standard
library. \MDd the multithread supporting, debug DLL standard library. You
are linking with an external library that was build one of these ways, and
you code is building in another.

2. Re the run-time error
The real distinction is between the Debug mode build on one hand and the
RelwithDebInfo, and Release mode builds on the other.
If it crashes in the Debug mode, but not in the Release/RelwithDebInfo
modes, then ther is almost certainly a problem with your code. It could be
that the oprimised version is not doing as much error checking and is
happily ignoring the problem, or the the re-arrangement of the code and data
in the optimised version means that a wayward pointer write is damaging a
less critical area of memory.