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

Ben Discoe ben at vterrain.org
Wed Oct 25 04:36:35 EDT 2006


Not to flog a dead horse here, but i do have something useful to add:

> -----
> From: Simon Perkins [mailto:sy at perkins.net] 
> Sent: Tuesday, October 24, 2006 6:47 AM
> 
> 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 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 [..]
> A real pain, if you ask me.

It is something of a pain, but not _every_ library needs it.  Only those
that do things like share the heap or pass file descriptors.  Let me give an
example.  My project (VTP) has around 16 library dependencies.  Some need to
be built on the same runtime library (and runtime version!), some do not:

Must be built with same runtime (/MDd vs. /MD, VC7.1 vc. VC8):
------------------
GDAL
wxWidgets
OSG, OpenThreads
zlib (if using the gzdopen function)

Does not need to match (Can be /MD, or built with older or non-VC compiler):
-------------------
libpng
libjpeg
libcurl
netcdf
QuikGrid
bzip2
expat
freetype
libMini
PROJ.4
unzip
zlib (if not using the gzdopen function)

>From this, i hope you can see that the pain is not that widespread.

> and make sure
> my library path and PATH are set appropriately when compiling /
> testing my code.

You can put your debug and release DLLs (e.g. gdal.dll and gdald.dll) in the
same folder on your path so there is nothing to switch.

-Ben




More information about the Gdal-dev mailing list