> > Cool, thanks for figuring this out.
I still wasn't happy with this .dSYM business so I went ahead and since apparently no one from MCS can answer this ;-) I went ahead and asked Jason Molenda after finding this page: http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme "I understand why it was chosen to separate debug information from a release but I am still unclear as to why there (or is there a way?) is no option for *force* debug information into the executable? Furthermore, if I am creating a shared/dynamic library and want to properly debug this in my test application, is there any way to force debug symbols into the library? Or am I forced to keep the .o's (or generate .dSYM) around?" You're out of luck here. We're trying to move to a model where the binary > that the compiler emits is what goes out the door. You still need to strip > out the non-exported symbols today but maybe some day we can address that as > well. You can create a .dSYM bundle by running dsymutil on the executable > while the .o files are still present on the computer and ship the .dSYM > bundle along with the shared lib. I know that's a hassle compared to just > sending around a .dylib. > The most common use case for our developers is that the debug info is not > shipped out - most programs are distributed without any debug > information/symbols; the dSYM and maybe the symbol-rich executable are kept > in-house for debugging and analyzing crash reports from the field but that's > it. So, bottom line, there is no way to use shared/dynamic libraries that contain debug information. Either use .dSYM / .o's or static libraries. Jason and I had some more dialog about static libraries but since we don't build PETSc universal nor distribute binaries, it's mostly irrelevant. Hope this finally clears up the issue. Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20100413/28c06bdd/attachment.html>
