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

[Simon Perkins]

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

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

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.

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.

Cheers,

Sy

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20061023/65fd375c/attachment.html