<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Ben Discoe wrote:<br>
<blockquote cite="mid003901c6f663$6e09a980$6501a8c0@DellWork"
type="cite">
<blockquote type="cite">
<pre wrap="">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
</pre>
</blockquote>
<pre wrap=""><!---->
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.
</pre>
</blockquote>
<br>
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
found error.<br>
<br>
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:<br>
<br>
(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).<br>
<br>
(b) Incorporate the CRT "merge module" into your installer package that
will then install the CRT in the global cache if required.<br>
<br>
(c) Have the user install the runtime libraries separately using the
VS8 CRT installer (available on MS's site)<br>
<br>
<br>
<blockquote cite="mid003901c6f663$6e09a980$6501a8c0@DellWork"
type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->
Yes, you should _always_ build your application and GDAL with the same
version of the runtime library (/MD, or /MDd).
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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!<br>
<br>
<br>
<blockquote cite="mid003901c6f663$6e09a980$6501a8c0@DellWork"
type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
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
files. <br>
<br>
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 forward.<br>
<br>
If I get the time I might look into CMake, but if anyone else beats me
to it, I wouldn't be offended... :)<br>
<br>
<blockquote cite="mid003901c6f663$6e09a980$6501a8c0@DellWork"
type="cite">
<pre wrap="">
The makefile.vc file would need a lot of other work to produce correct and
suitable VC8 DLLs. Again, avoid it if possible.
</pre>
</blockquote>
<br>
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.<br>
<br>
Cheers,<br>
<br>
Sy<br>
<br>
</body>
</html>