[Gdal-dev] Visual Studio 2005, GDAL and Manifests

[Mateusz Loskot]

Simon Perkins wrote:
> In any case, if I really do have to use the same CRT throughout all my
> code, I seem to have two options:
> 
> (a) Compile separate versions of GDAL and all my other third party DLLs
> in both debug and release modes (i.e. with both /MDd and /MD), keep the
> import libraries and DLLs separate, and make sure my library path and
> PATH are set appropriately when compiling / testing my code. A real
> pain, if you ask me.

You're likely asking for troubles when mixing debug and release
dependencies. Debug and release libraries use different memory
allocators, etc. Generally, linking against multiple versions of CRT is
not supported by VC++.

That's why Microsoft's concept of cycle of development is based on
run-time modules compiled as Release and development modules compiled as
Debug and shipped in a SDK package by vendors.
So, according to Microsoft style of development, developer is
supposed to use Debug versions of every libraries he uses.
Visual C++ IDE supports it by physically separating Debug and Release
files to <project>/Debug and <project>/Release.


Personally, regardless if I use VC++ IDE or nmake with makefiles,
I always name DLL using following scheme

1) Debug:
<module>d.dll
<module>d_i.lib

2) Release:
<module>.dll
<module>_i.dll

Next, test program / executable linked against Debug version is named as
<program>d.exe but linked against Release as <program>.exe.

Yes, it requires some configuration steps in VC++ project or makefiles,
but finally I've never met any conflicts. Also my PATH stays clean.

Finally, and I think most *important* here, is that according to Visual
Studio EULA, you can NOT redistribute Debug modules of Microsoft C
Run-Time. This also explains why it's hard to deploy and run debug
versions on machines where no Visual C++ IDE and SDKs are installed.

> (b) Compile everything with /MD, but disable optimization in those
> sections of code I want to debug. Also ensure that the _DEBUG flag is
> undefined everywhere to avoid _CrtDbgReportW() link errors.
> 
> I've been using (b) and so far it seems to be working fine. I can step
> through code, set breakpoints etc.

I'd say such builds are not usable for serious development and debugging.

> Out of curiosity, does using the debug CRT provide any benefit that
> anyone knows of? I guess it allows you to step into some of the standard
> C/C++ library routines, but that seems like a relatively small win for
> the extra pain...

You can try to run following program compiled in Debug, in Release, and
compare which version is better for a developer:

#include <stdlib.h>
int main( void )
{
    wchar_t buf[20];
    mbstowcs(buf, NULL, 20);

    return 0;
}

Cheers
-- 
Mateusz Loskot
http://mateusz.loskot.net