[gdal-dev] [GDAL 1.5.1] How to build and run GDAL 1.5.1 on windows

Lucena, Ivan ivan.lucena at pmldnet.com
Fri Aug 8 09:37:21 EDT 2008


I would like to exchange my experience on the VS debugging part, if I may.

If you load one of the "fake" VC projects from the GDAL source 
distribution, makegdal71.vcproj or makegdal80.vcproj, it is pretty easy 
to write in the Project Property Pages/Debugging what are your settings 
for test anything basically. Ex.:

Command: D:/gdal/apps/gdal_translate.exe
Command Arguments: -of gtiff input.vrt ouput.tif
Working Directory: D:/Data/Test
Environment: CPL_DEBUG=ON

One note about environment variables, VS2003 doesn't have one entry for 
"Environment" on the Project Property Pages, VS2005 does. But you can 
always set them directly on windows. Just remember to close and open 
VS2003 again so that it will catch the changes.

To run in debugging mode is pretty simple. You don't necessarily need to 
create a complicate VS Solution and add several projects to it. Just add 
the other project source folder to your source tree on "Solution/Explorer"

Just click on the left side of your source code line to make that little 
red dot to show up and click on "Debug/Start".

I have used that to launch other application that would ultimately load 
GDAL dll during the execution like:


Command: "C:\Program 


Command: "C:\Program Files\ESRI\bin\ArcMap.exe"

But another option is to attach to one existing/running process by using 
the "Debug/Process" options.

I used to start PythonWin first and then attach to its process and make 
calls to the specific function to test specific part of my code. It is 

If you are developing a driver that is not on the trunk yet you can run 
the "fake" VS project generator that I wrote:

D:\GDAL > makegdal_gen.bat
Usage: makegdal_gen "MS Visual C++ version" > makegdalNN.vcproj
    makegdal_gen 7.10 > makegdal71.vcproj
    makegdal_gen 8.00 > makegdal80.vcproj

That will update the source file tree.

Of course you can do that with XEmacs or GDB but VS is just more 
comfortable and maybe improve your productivity to solve problems.

By the way, does anybody interested in developing a KDeveloper project 
for GDAL? I can do that if there are demand for it. :)

Best regards,


Mateusz Loskot wrote:
> Cherif Oueslati wrote:
>> Hello every body,
>> I found a problem to run the GDAL 1.5.1 in a MS Visual Studio 2003
>> Environment, to test the implementation of a driver that i developed.
>> The error appears when i would like to run the project and indicates 
>> that it
>> is impossible to begin the debug because it's impossible to start the
>> "gdal15.dll".
> Cherif,
> This is correct, you can no *run* a DLL (if you mean this as "start the 
> gdal15.dll") in any version of Visual Studio.
> You need to add your own test program (.exe project) and attach its 
> project to the solution, configure dependencies and set your test 
> project as startup project.
> If you don't know how to do it, refer MSDN and VS documentation:
> http://msdn.microsoft.com/en-us/library/0bxe8ytt.aspx
>> Someone suggest to me to well define the "environment variables".
>> Can you tell me how could i run gdal 1.5.1 or how to set the "environment
>> variables" inside the visual studio it self.
> All this is well explained in the VS documentation:
> http://msdn.microsoft.com/en-us/library/aa909648.aspx
> But please notice, you do need to set environment variables to be able 
> to fully debug and test GDAL dll, but environment variables does not the 
> first problem. You still need to create a project for test program (.exe 
> application).
> Another option but IMHO more difficult if you are not experienced with 
> VS and debugging, as Tamas suggested, is to attach debugging session to 
> a process started as .exe program, for example gdalinfo or ogrinfo.
> In case you don't know how to configure and use Visual Studio debugger, 
> I recommend to read MSDN:
> http://msdn.microsoft.com/en-us/library/d0b8xh0y.aspx
> Best regards,

More information about the gdal-dev mailing list