Joel,
You could try to update the source code tree in your makegdal80.vcproj
file by running makegdal_gen.bat. Be aware that it will overwrite your
project's debugging and nmake options. The OPTFLAGS and the .pdb
generation will not be affect by that but I think that by updating the
source code tree VS will be able to perform step-into (F11) better. Not
sure.
Regards,
Ivan
Joel Odom wrote:
Problem solved. For the benefit of the group and the searchable list
archives, I'll describe here what was going on.
My build on Windows, using makegdal80.sln, was generating a gdal15.dll
with symbols and gdal15.pdb file. For whatever reason, these files
did not contain sufficient information for me to step in to the code
in a debug session. After poking around for some time, I found that
the OPTFLAGS in nmake.opt were set to the optimized build. I'm not
sure why I was seeing the debug symbols loading, but changing OPTFLAGS
to generate a gdal.pdb (along with the gdal15.pdb) gave me the debug
information I needed. (In 1.6.0, the OPTFLAGS is set for debug when
DEBUG is defined, which seems to make more sense.)
On Fri, Dec 19, 2008 at 11:22 AM, Joel Odom <[email protected]> wrote:
More notes on the issue below.
---------- Forwarded message ----------
From: Joel Odom <[email protected]>
Date: Fri, Dec 19, 2008 at 11:21 AM
Subject: Re: [gdal-dev] Debugging on Windows Using Visual Studio
To: Frank Warmerdam <[email protected]>
I'm building from makegdal80.sln. I'm also starting my debug sessions
from this same solution. I'm getting symbols in gdal15.dll and the
.pdb file, but I still can't set a break point anywhere. It's like
the debug symbols don't map correctly to the source code.
I'm wondering if there is some flag in the makefile options that is
not being set, so the program debug information is incomplete? I am
able to set a break point in my dll that calls gdal, but not anywhere
in the gdal methods. Again, this is all in VS 2005. I'll post an
answer here if I figure out the problem before I give up, but if
anyone has any ideas, I'd appreciate it.
On Fri, Dec 19, 2008 at 11:10 AM, Frank Warmerdam <[email protected]> wrote:
Joel Odom wrote:
Bruce. I'm trying to debug an app that uses GDAL from unmanaged C++
on Visual Studio 2005. I've tried for an hour or two to step into
gdal, running debug sessions both from the project file from which I
build gdal and from the app that calls into GDAL, but even when I run
from the gdal solution itself, it still doesn't let me step through
source code, even though the modules window says gdal15.dll is loaded
with symbols from the same location as my .pdb file.
Joel,
I have generally not had problems with this. Did you build GDAL using
the nmake files or the solution? I've had good luck debugging the
utilities and into GDAL itself with visual studio. I normally run things
from the commandline and pop into visual studio when things crash (even
triggering crashes at select points).
This is usually with visual studio 2003.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam,
[email protected]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | Geospatial Programmer for Rent
--
http://giscoder.blogspot.com/
--
http://giscoder.blogspot.com/
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
