Suppose that I compiled a dynamic library (Windows DLL and/or Linux shared object file, .so) in debug mode for use by a client application that links to it dynamically. My source code is available to the client application developer.
I need some clarification regarding the following debugging scenario. I’ve always understood/assumed that in order for the client application to debug into my library
(for e.g. in order for a client application developer to step into my source code while debugging, say using F10 in MS VC++), that they would have to have actually built a local copy of my libraries themselves (with access to my source code), or atleast have local access to my source code without having built it (not sure if that would suffice?).
Am I right on this? In other words, I think it is not merely enough to provide libraries with debugging symbols (PDB files in MS VC++) if the client application is linking dynamically to my application which has itself been built dynamically. Appreciate if anyone can help sort this out for me? How about the situation in Linux? My understanding again is the same as the above. Now if I had compiled a static library (Windows LIB and/or Linux library .a); my understanding is that the they then don’t need to have a locally build copy of my source code (I haven’t tried this one out yet)?
Is/are my premise(s) correct? If not, can someone kindly provide some detailed explanation preferably with an example? Thanks for your input.
As requested, here’s my comment as an answer. Since it only addresses the Windows side of things, anybody who has the Linux (or Mac!) part of the answer is free to edit it in (I’ve marked this as a community wiki answer).
For VC++, the debug build DLL + matching PDB + matching source is all you need. The hard part is getting them all to match 😉
Also, it works more smoothly if the source files are at the same path as when the DLL was compiled, but Visual Studio is also perfectly capable of prompting you to browse to the source manually if you have it.