[Gdal-dev] Visual Studio 2005, GDAL and Manifests
sy at perkins.net
Mon Oct 23 12:17:54 EDT 2006
Ben Discoe wrote:
>> The problem I have been getting is that I've been unable to
>> compile applications in Visual Studio 2005 using the /MDd
>> compile switch (link with the debug C runtime), when I link
>> them against the GDAL library compiled with the /MD switch
>> (link with the non-debug CRT, which is what the GDAL
>> makefiles do). Doing this results in a "MSVCR80.DLL not found"
>> error when I try to run the program. Compiling my code with
>> /MD fixes things
> Note that it doesn't really "fix" things. It just happens to work if the
> machine you're running on already has the release-mode runtime library DLLs
> (msvcp80.dll, msvcr80.dll). Some machines will have this, especially if
> they have some recent .NET framework installed.
Note that I'm ONLY talking about development builds here. Until I made
the fixes I described earlier, I couldn't get my code to run at all
(compiling with /MDd, linked against GDAL compiled with /MD), e.g. for
debugging within Visual Studio without giving me the MSVCR80.DLL not
For distributing apps, then sure, you have to worry about giving people
the CRT libraries. But then I'd be compiling everything in release mode
anyway. As I understand it, the correct way(s) to do this with Visual
Studio 2005 are:
(a) Distribute the Microsoft.VC80.CRT assembly directory found in the VC
redist directory as a sub-directory of your application's directory
(this is the "private assembly" approach).
(b) Incorporate the CRT "merge module" into your installer package that
will then install the CRT in the global cache if required.
(c) Have the user install the runtime libraries separately using the VS8
CRT installer (available on MS's site)
>> but this is not the default for Visual
>> Studio debug builds, and simply changing the switch to /MD
>> breaks other things in the debug build.
> Yes, you should _always_ build your application and GDAL with the same
> version of the runtime library (/MD, or /MDd).
OK, that's nice in theory, but in practice I found it to be a bit of a
nightmare. It's not just GDAL I have to worry about, but a host
(alright, a small host...) of other third party DLLs that my application
depends upon. Most of those do not have .vcproj files, and many of them
have build scripts that only build with /MD, rather like GDAL's
makefile.vc. Maintaining separate debug and release versions of each of
those DLLs, plus their associated import libraries, and making sure that
the library paths are set correctly during builds, and the PATH is set
correctly during debugging / testing, is a pain in the butt. The debug
and release versions of the files all look the same of course and it's
very easy to make mistakes. I'm sure I'm not the only person who finds
it much easier to just maintain release versions of those third party
libraries, and to just switch the code I'm working on between release
and debug compiles.
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.
But to avoid these issues completely, AFAIK, under VS 2003, it was quite
common to always compile with /MD, even when debugging. However, VS 2005
has made this harder. If you just change your debug configuration to
build with /MD instead of /MDd, you'll see lots of linker errors about
not finding _CrtDbgReportW(). This is a function that is inserted into
debug builds, but is only found in the debug library. You can fix this,
by undefining _DEBUG, but I don't know what other consequences that has.
I think the debug vs release CRT thing is poorly thought out in
general... We don't have this problem on Linux!
> Unless, of course, you're trying to use makefile.vc, which i strongly
> recommend to avoid. There is no way VC8 can fix it when upgrading from VC7
> to VC8 standards. Use gdal.vcproj.
gdal.vcproj is a splendid thing, but has two problems. First, it's not
part of the canonical GDAL distribution. Second it's significantly more
tedious to do custom configurations, e.g. linking against optional third
party libraries such as MrSID, JPEG2000, FITS, etc, than it is with the
nmake.opt config file used with the makefile.vc builds.
I've used the makefile.vc build under VS 2003 for several years with no
problems. I've had some issues with VS 2005, as described, but I think
I've just about got it cracked now. I think with the manifest embedding,
it'll work OK. Not nearly as nice as a project file if you're interested
in debugging GDAL, agreed, but it's easy to use and configure.if you
just want to use GDAL as a black box.
A few weeks back, I started a discussion about adding VS 2005 project
files to the GDAL distribution. One of the concerns raised was the
plethora of different build scripts that GDAL is becoming encumbered
with. We already have GNU makefiles and makefile.vc, a partial
implementation of WinCE project files, and unofficial VS 2003 project
One solution that has been suggested is to embrace a universal build
system like Cmake, with which we can maintain one set of scripts, and
then generate project files, makefiles, or whatever as needed. I've only
used CMake as a user rather than a developer, but it seems to me this
would also solve the configuration problem. CMake has an interactive
configuration phase, and generates native build scripts for any platform
you can think of. Personally, I think this is the best idea for moving
If I get the time I might look into CMake, but if anyone else beats me
to it, I wouldn't be offended... :)
> The makefile.vc file would need a lot of other work to produce correct and
> suitable VC8 DLLs. Again, avoid it if possible.
Apart from embedding the manifests into the DLLs and executables, what
other changes do you think need making? With my latest fixes, I can
produce DLLs that seem to work fine in my VC8 applications.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Gdal-dev