[MacPorts] #34491: add dsymutil to post-destroot in gdb compatible compilers
MacPorts
noreply at macports.org
Sun Jun 10 02:01:15 PDT 2012
#34491: add dsymutil to post-destroot in gdb compatible compilers
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Reporter: sean.michael.farley@… | Owner: macports-tickets@…
Type: defect | Status: closed
Priority: Normal | Milestone:
Component: ports | Version: 2.1.0
Resolution: fixed | Keywords: haspatch
Port: apple-gcc40, apple-gcc42, llvm-gcc42, llvm-2.9, llvm-3.0, llvm-3.1, llvm-3.2, clang-2.9, clang-3.0, clang-3.1, clang-3.2, dragonegg-3.0, dragonegg-3.1, dragonegg-3.2, g95, gcc42, gcc43, gcc44, gcc45, gcc46, gcc47, gcc48 |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
Comment(by sean.michael.farley@…):
Replying to [comment:11 jeremyhu@…]:
> I don't think we should be in the habit of shipping dSYMs along side the
binaries. If we want the debug symbols, we should just not strip the
binaries...
>
> I'm sorry, I was confused. I thought that nostrip was an option in
/opt/local/etc/macports.conf, but it's not. I'm not sure what the
appropriate knob is for that, hopefully someone else can chime in on
that...
Not stripping the binaries is something from the linux world where
binaries and libraries can be augmented with debug symbols usually by just
using the -g option (and not stripping the output). I contacted the Apple
compiler team about this a year or so ago:
Me:
"I have been reading your entry at:
http://wiki.dwarfstd.org/index.php?title=Apple's_%22Lazy%22_DWARF_Scheme
and think 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?
Jason Molenda <jmolenda at apple.com>:
"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 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."
I have been following this model and it has worked perfectly for a few
years now. The most important ports to run dsymutil on are the gcc-type
compilers so that debugging doesn't blow up.
--
Ticket URL: <https://trac.macports.org/ticket/34491#comment:12>
MacPorts <http://www.macports.org/>
Ports system for Mac OS
More information about the macports-tickets
mailing list