RE: [xml] Win32 Facelift No.2

["Igor Zlatkovic" <izlatkovic daenet de>]

Hello,

> It's nice to be able to get a stack trace with the actual 
> code I will be using [...]

Okay, you are right. It is convenient to see the call stack filled with
the actual function names instead of hex addresses. Beginning with the
next release, I shall deliver PDBs together with the binaries.

> I have several occations where things 
> work in debug
> but not release, and it's hard to find those leaks!  

But... libxml binaries are always release, optimised. When using the
binary kit, you link to physically the same libxml, no matter if you are
building a debug or a release of your app. Following that, libxml binary
either works or it doesn't, it does not depend on the build
configuration of your program. What you are describing can be a
programming error or a compiler optimisation bug that affects your code,
but not libxml. I know those problems you talk about, Gods know I have
had them myself more than I care to count, but are you sure libxml's PDB
would help you there?

> Most of my work
> involves the extension api, so I am usually debugging my code 
> but being able
> to dive into the libxml stuff is very helpful.

Hmm... It seems I am misunderstanding something. If you wish to dive
into the libxml during a debug session, then you need the source code,
and that exactly the same surce code which was used to build the binary
you linked to. Without source code, PDB shall only give you nicer call
stack outlook. You shall be diving without oxygene and that's no fun.
Enlighten me.

I must still check if I can build a PDB against the optimised ilbrary
without affecting it. Turning on the debug info generation automatically
disables few optimisations and I would like to have those optimisations.
If the library is affected, well, then I must distribute an additional
binary with PDB. Either way, you shall get the PDB and I hope it helps
you.

Ciao
Igor