[petsc-dev] Apple sadness

[Satish Balay]

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
>