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

[Simon Perkins]

> > Yes, you should _always_ build your application and GDAL with the same
> > version of the runtime library (/MD, or /MDd).
> >   
> 
> Now, I am aware of a few problems with this approach. In particular, the 
> debug and release CRTs use different memory allocation procedures, so if 
> you allocate memory in some library code compiled with /MD and then 
> release it in your calling code, compiled with /MDd, you'll get crashes. 
> And if you're passing STL containers around that do automatic memory 
> management, this is an easy trap to fall into. But if the third party 
> libraries are relatively simple and are pure C, then you can probably 
> get away with it. In any case, code you give out will be compiled in 
> release mode and so won't be affected by this problem.


I've been playing a bit more with the code and want to revise my earlier
opinion...

Although my code is now starting up OK (an improvement on where I was a
couple of days ago), as yet, I've been unable to get even relatively
simple code compiled with /MDd to run correctly with DLLs (e.g. GDAL)
compiled with /MD under Visual Studio 2005. I get a segmentation fault
when I call GDALOpen() in my code, for instance. Now, I thought I used
to be able to do this kind of thing with VS 2003, so either I'm
mis-remembering, or VS 2005 has made the debug and non-debug CRTs more
incompatible.

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.

(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.

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...

Cheers,

Sy