Sean, One issue we discussed was the discrepancy between gcc [calling dsymutil] - but not gfortran. I posted this to gfortran list. You might be interested in the responses..
http://gcc.gnu.org/ml/fortran/2010-04/msg00131.html satish On Tue, 13 Apr 2010, Sean Farley wrote: > > > > 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 >
