stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: [PING] Re: svn commit: r588290 - /incubator/stdcxx/branches/4.2.x/etc/config/windows/projectdef.js
Date Tue, 06 Nov 2007 00:10:39 GMT
William A. Rowe, Jr. wrote:
> Martin Sebor wrote:
>> I meant the problems that Liviu was talking about. I.e., if someone
>> is using a debug build of stdcxx 4.2.0 on Windows, will they be able
>> to step through stdcxx code? If not, I think it would be worthwhile
>> to document why and point them to a patch they can download to make
>> it possible (i.e., your change), or explain how to do it otherwise.
> They can step through a debug or release build.

Thanks, I did not know that.

> What is especially nice
> about using the (/Zi) flag to cc and (/debug /opt:ref) flags to link.exe
> is that your .exe looks like a unix stripped binary, no extra debugger
> noise, but that the .pdb contains all the binary -> source/diagnostics
> you would wish from a unix -g build (unstripped).

Right. The GNU strip command makes it possible to create a similar
file that is then readable by gdb but I don't think it's a widely
used feature:

> All that's required is that your favorite win debugger/dr watson can
> see the .pdb alongside the binary (or you put in some horribly complex
> pathing or resolve to a symbol server), and that somewhere you have
> the sources where the debugger can load them up.  It will prompt the
> user for "where is foo.c?"

I think I understand this part: The .pdb file needs to be in the
same directory as the library for the debugger to find it on is

IIUC, in 4.2.0 we have it in the wrong directory and Farid's patch
makes the linker put in the same directory as the lib. Do I have
it right, Farid?

> In httpd, I'd simply set up a subdirectory of binaries (and I've now
> moved all of this to
> in the symbols/ subdirectory - so it never hits www. mirror server) and
> the rare soul who wants the symbols just unzip's them right on top of
> an installed program.

Super nifty! A repository of prebuilt binaries for all supported

We might want to think about something like this (only for the
most common configuration of the library, i.e., optimized, thread
safe, shared lib).

> If they really use a "debug" build, that's a different story, you want
> those to use /O- no-optimization flags so that single stepping is not
> half as confusing ;-)

I'm pretty sure we do that, right Farid?


View raw message