Motivation for Question: Generating 64-bit and 32-bit code requires two seperate full-program-compiles, and when using visual studio (as detailed below) release and debug builds are incompatible, therefore seemingly requiring another two full-program-compiles (bringing the total up to four). I would like to stick with two full-program-compiles, but I am confused.
When Debugging All I Care About Is: the global state, the stack frame, and the line-number/file of the code that caused the crash. Also, I don’t care about debug info from peer-reviewed highly-stable open-source libraries; therefore, I don’t need debug-info for those libraries and a release build for this libraries should be adequate.
Evidence: I know that, in VS, if you compile a debug version of an application and link it with a release version of Google Protocol Buffers, the produced code will fail due to a side-effect of mixing release/debug types.
I would like to know if this is a side effect of using visual studio, and a certain set of compiler switches make it so.
Secondly inspecting the build scripts/processes of opensource projects it seems that it is OK to mix code generated in debug mode with code generated in release (for example mumble). I guess this has something to do with the distinction between release and ReleaseWithDebugInfo (term borrowed from cmake, but this is obviously expressable within Visual Studio). ReleaseWithDebugInfo is afterall an optimised version of the binary, with debugging info also generated, and therefore suitable for release.
The Questions :
- Could someone please explain, or provide references, as to what switches make the code incompatible.
- Is the ReleaseWithDebugInfo style of compiling in visual studio enough for both debug and release use-cases (according to my criteria, as explained above)? –i.e., is whatever the compiler generates in debug mode overkill or redundant ?
- In ReleaseWithDebugInfo mode (for my application) can I compile external dependanies in release mode (without debug info) and not have any undefined behaviour ?
Whether debug mode (by which I take it you mean unoptimized) code is ‘overkill’ depends on what you want to do with it.
If you want to use the debugger, stepping lines very accurately and inspecting any variable you come across, you’ll need to turn off optimisation. If you don’t care some much about that, then you can leave it turned on, and put up with some strange behaviour in the debugger.
If you compile for edit-and-continue, there’ll be lots of padding put around the place to allow partial compiles/links.
So there is lots of ‘overkill’ and ‘redundancy’ to unoptimised code, but they may still be valuable.
The usual problem with linking different configurations is when they’re sharing objects allocated by different versions/configurations of the run-time-libraries. If you’re using a Win32-style ‘C’-style interface between libraries, then you rarely care if one’s debug and one’s release. If you allocate a CString on the heap with one version of the run-time, and then pass it to code which deallocates with a different run-time, then there will often be problems.
There are three different things you need to think about here:
It’s only the last one you really need to get perfect. The other two are personal preference.