1

I work for a camera company and we provide an SDK for our customers. Historically we only provided a release build of our SDK that was built against the non-debug CRT. As part of our SDK package we provide a number of examples on how to use the SDK. The examples have Debug project configurations which use the debug CRT. In some cases we run into strange behaviour due to the fact that these examples and the library that they link against use different CRT's.

My questions is what is the appropriate way to deal with this sort of situation? Should we be distributing a debug version of our library that uses the debug CRT? As long as we don't provide a pdb or at most a stripped pdb, then all proprietary information should still remain hidden. Is it correct to assume that in doing this there should be no other negative effects other then a larger, not optimised binary?

Is it common practice to distribute a debug binary linked against the debug CRT or should we just continue distributing only the release build?

drb
  • 728
  • 8
  • 21
Mat Gara
  • 13
  • 3
  • 2
    I don't think Microsoft allows you to distribute the debug CRT in any way, so you're stuck if they don't already have it. – Mark Ransom Sep 21 '11 at 16:05
  • We don't plan to distribute the debug CRT itself. We just want to distribute our library built against Microsofts debug CRT. The end user will still need to acquire the actual debug CRT from Microsoft directly. If they don't, the dubug versions of our examples will not run on their machine due to the missing debug CRT. – Mat Gara Sep 21 '11 at 16:23

2 Answers2

2

Yes, you'll need to distribute Debug and Release builds of your library. Built with respectively /MDd and /MD so the CRT can be shared. Different versions too, built against, say, the VS2005, VS2008 and VS2010 versions of the CRT.

This is of course painful. To narrow it down to a single library, you'll need to carefully craft your public interface so it doesn't expose any C++ objects or any pointers that need to be released by the client code. Exceptions are also taboo. A common solution is to use COM. Especially an Automation compatible interface is useable by most any language runtime in common use on Windows.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
0

You might consider an Optimized Debug build, where it is set to use the debug versions of the libraries but has all the optimization flags set as they would be in a Release build. This will prevent subtle differences in execution from affecting the user experience.

Mark Ransom
  • 299,747
  • 42
  • 398
  • 622