0

The reason I want to do this is because the debug libraries are littered with extra "assertion" statements that take ages to start with during remote debugging.

I hope it's only to replace Multi-threaded Debug DLL (/MDd) with Multi-threaded DLL (/MD) in Code Generation -> Runtime Library but I wonder if there are other changes one has to take into account as well?

IODEV
  • 1,706
  • 2
  • 17
  • 20
  • Hmm. Does changing the runtime library to the non-debug version actually work? I thought maybe there'd be missing "debug-related" symbols, or some such, that your base project references. – Adrian Mole Nov 30 '21 at 13:53
  • ... or maybe a run-time error about the wrong value of something like `_debug_level_`? – Adrian Mole Nov 30 '21 at 14:00
  • Well, in theory I hope it should work to store the debug symbols for local app only and call the normal run time libraries. I mean the calling the debug or normal library shouldn't matter regarding the call sequence and parameters. I'll gave it a try but got some odd errors like `error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL'`. – IODEV Nov 30 '21 at 14:30
  • Yeah - That mismatch was the error I alluded to in my second comment. Couldn't remember what the symbol was actually called. There is possibly a workaround, by *forcing* the value of that symbol to what it needs to be, but I'm not sure how to do that. Maybe Google that symbol, or look for it here on SO? – Adrian Mole Nov 30 '21 at 14:31
  • I'll try it again with a complete clean rebuild but it's a rather large code base so it might take a while. Any idea how to fool the linker to use the normal runtime libraries besides forcing _ITERATOR_DEBUG_LEVE? – IODEV Nov 30 '21 at 14:33
  • Here's a possibly relevant SO post: [Mixing debug and release library/binary - bad practice?](https://stackoverflow.com/q/11658915/10871073) – Adrian Mole Nov 30 '21 at 14:37
  • Great, thanks! Found a similar one where he managed to fix things but without knowing how. https://stackoverflow.com/questions/65894941/error-lnk2038-mismatch-detected-for-iterator-debug-level-value-2-doesnt – IODEV Nov 30 '21 at 14:55
  • This is the answer I was looking for https://stackoverflow.com/a/55816027/1189659 ie it's doable. I'll just have to find where the debug definition is mixed up. – IODEV Nov 30 '21 at 14:58
  • Got it working although VS behaves somewhat strangely. When I forced `_ITERATOR_DEBUG_LEVEL` to 2, VS automatically switched linking to test mode which outputs `*-test.exe`. But well, that's another issue I'll have to save for another time. – IODEV Dec 01 '21 at 14:18

1 Answers1

0

This is doable and also good practice for remote debugging big and complex applications also exlained in Mixing debug and release library/binary - bad practice?.

Besides switching link libraries from Multi-threaded Debug DLL (/MDd) to Multi-threaded DLL (/MD) one needs to take into account debug macros like _ITERATOR_DEBUG_LEVEL which might otherwise conflict during linking. A typical error message that indicates such a conflic is error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL'

Once all the conflicting macros have been resolved it will link to the standard runtime libraries but the debug symbols for the application remains.

Also, @Adrian Mole thanks for the assistans in this matter.

IODEV
  • 1,706
  • 2
  • 17
  • 20