add dsymutil to post-destroot in gdb compatible compilers

[sean.michael.farley@…]

For compilers that are gdb compatible (c, c++, and fortran), the portfile _really_ needs to keep the debug symbols. This patch fixes dsymutil being called for apple-gcc4{0,2}, gcc4{2,3,4,5,6,7,8}, {clang,llvm}-{2.9,3.0,3.1}, and dragonegg-3.{0,1,2}. This has the nice effect of also fixing the fortran errors reported here:

​http://lists.macosforge.org/pipermail/macports-dev/2012-May/019098.html

and

​http://lists.macosforge.org/pipermail/macports-dev/2012-May/019300.html

[sean.michael.farley@…]

patch compiler portfiles to keep debugging info

[ryandesign@…]

Replying to sean.michael.farley@…:

This has the nice effect of also fixing the fortran errors reported here:

The gmp patch leaves unnecessary code in the Portfile. The default compiler will never be llvm-gcc-4.2 on Xcode 4.2 and up. On the mailing list I ​already provided the simpler block that should be used, provided it is actually verified by someone with Xcode 4.1 that that was really the problem.

[ryandesign@…]

I also don't see that the gmp patch has anything to do with the rest of this ticket.

[sean.michael.farley@…]

Replying to ryandesign@…:

Replying to sean.michael.farley@…:

This has the nice effect of also fixing the fortran errors reported here:

The gmp patch leaves unnecessary code in the Portfile. The default compiler will never be llvm-gcc-4.2 on Xcode 4.2 and up. On the mailing list I ​already provided the simpler block that should be used, provided it is actually verified by someone with Xcode 4.1 that that was really the problem.

Compiling with clang on 4.2 is fine (and I have tested). gcc-4.2 isn't installed with Xcode 4.3 (only left over from a previous 4.2 installation) so one of the llvm compilers need to be used. In fact, both llvm-gcc-4.2 and clang work for Xcode >= 4.3

[sean.michael.farley@…]

Replying to ryandesign@…:

I also don't see that the gmp patch has anything to do with the rest of this ticket.

This could very well (and probably should) be split up into two patches (or someone with write permission just commit them separately) but I wanted to be sure that both get applied so that the buildbot will correctly build the compilers.

[jmr@…]

Applied Xcode 4.1 change to gmp in r94119. (And yes, that is completely unrelated to the ticket summary.)

[sean.michael.farley@…]

Replying to jmr@…:

Applied Xcode 4.1 change to gmp in r94119. (And yes, that is completely unrelated to the ticket summary.)

Yay! Thanks a lot jmr! Any chance that someone can give a review of the rest of this patch (the dsymutil part)? I think the patch needs to be regenerated due to revisions having already been bumped but accepting this kind of patch would really, really help out our community. Thanks in advance!

[jeremyhu@…]

This seems like the wrong approach to me.

Also, how does this solve the issue reported on the list?

[jeremyhu@…]

Oh, fixing gmp's build is what solves that mailing list issue...

You really should've filed two separate bug reports. That was confusing.

As for creating dSYMs for all the dylibs, no that just seems like a bad idea... Just set dostrip to false if you don't want to strip your binaries.

Closing as fixed, since the gmp issue is fixed...

[sean.michael.farley@…]

Replying to jeremyhu@…:

Oh, fixing gmp's build is what solves that mailing list issue...

You really should've filed two separate bug reports. That was confusing.

Sorry about that. Yes, I should have filed two separate bug reports; I was trying to keep these two linked but that seemed to cause more trouble.

As for creating dSYMs for all the dylibs, no that just seems like a bad idea...

Why are creating dSYMs a bad idea? My understanding is that they are just the debug symbols so they interfere with nothing?

Just set dostrip to false if you don't want to strip your binaries.

Hmm, I can't find much on this variable; could you elaborate? As far as I understand, (had to dig up an old thread from Jason Molenda) there is no way to add debug symbols to shared libraries on the mac; hence the only way is to create the dSYMs

Closing as fixed, since the gmp issue is fixed...

Well, actually, this ticket was meant for the debugging symbols that are missing from the gcc-derived compilers. I just tested this with a brand-new MacPorts installation and I have attached the output of what I'm still seeing with missing symbols. All of this is fixed running dsymutil. Is it possible to include this information without dsymutil? I didn't think it would be possible but am open to suggestions.

[sean.michael.farley@…]

missing symbol output

[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...

[sean.michael.farley@…]

Replying to 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@…>: "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.

[suv-sf@…]

Cc Me!

[jeremyhu@…]

Yes, you can put debug symbols into the binary. It's also possible to ship them separately from a stripped binary.

I usually build debug versions like:

clang -g3 -gdwarf-2 -O0 -c test.c
clang -o test test.o

test will have debug symbols in it.

[jeremyhu@…]

Ah, sorry. I didn't finish reading your response.

Yes, there are no symbols in the binary itself, but there are references to the object files. Running strip (or install -s) will remove those references.

As for shipping the dSYMs, that will give you the debug symbols, but you won't have the src to match it up with. If you want to debug a particular package, your best bet is just to use -k to not erase the objs and src.

[sean.michael.farley@…]

Replying to jeremyhu@…:

Yes, you can put debug symbols into the binary. It's also possible to ship them separately from a stripped binary.

I usually build debug versions like:

clang -g3 -gdwarf-2 -O0 -c test.c
clang -o test test.o

test will have debug symbols in it.

That's only for statically linked libraries. The problem here is that gcc4X builds shared libraries and the only way to keep the debugging symbols are with .dSYM bundles. Since MacPorts is shipping gcc4X without the .dSYM debugging blows up for *any* executable. Using your example:

$ gcc-mp-4.7 -g3 -gdwarf-2 -O0 -c test.c
$ gcc-mp-4.7 -o test test.o

still produces the output:

$ gdb ./test
GNU gdb 6.3.50-20050815 (Apple version gdb-1752) (Sat Jan 28 03:02:46 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...No symbol table is loaded.  Use the "file" command.
Breakpoint 1 (PetscError) pending.
Reading symbols for shared libraries ..
warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libgcc/_muldi3_s.o" - no debug information available for "../../../gcc-4.7.0/libgcc/libgcc2.c".


warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libgcc/_negdi2_s.o" - no debug information available for "../../../gcc-4.7.0/libgcc/libgcc2.c".


warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libgcc/_lshrdi3_s.o" - no debug information available for "../../../gcc-4.7.0/libgcc/libgcc2.c".


warning: Could not find object file "/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_gcc47/gcc47/work/build/x86_64-apple-darwin11/libgcc/_ashldi3_s.o" - no debug information available for "../../../gcc-4.7.0/libgcc/libgcc2.c".

Full output and test.c are attached.

[sean.michael.farley@…]

sample test.c

[sean.michael.farley@…]

full gdb output of test.c

[sean.michael.farley@…]

Replying to jeremyhu@…:

Ah, sorry. I didn't finish reading your response.

Yes, there are no symbols in the binary itself, but there are references to the object files. Running strip (or install -s) will remove those references.

As for shipping the dSYMs, that will give you the debug symbols, but you won't have the src to match it up with. If you want to debug a particular package, your best bet is just to use -k to not erase the objs and src.

I think in general that is fine. The only ports that really need this are the compilers since they're producing the object files. It would be nice if the buildbot took care of this since compiling all the ports listed in the patch takes quite a while.

[jeremyhu@…]

So what is the actual problem that you are trying to solve?

If you want to debug gcc47's runtime bits, then use '-k' to keep those object files around.

If you are just concerned about the messages printed by gdb, then perhaps we should just strip those object files.

In any event, if you think there is still something actionable, please open a new ticket since this one is a bit scattered =)

[sean.michael.farley@…]

Replying to jeremyhu@…:

So what is the actual problem that you are trying to solve?

If you want to debug gcc47's runtime bits, then use '-k' to keep those object files around.

If you are just concerned about the messages printed by gdb, then perhaps we should just strip those object files.

In any event, if you think there is still something actionable, please open a new ticket since this one is a bit scattered =)

Fair enough :-) I'll open a new ticket with an updated patch and address these questions there. Thanks for the feedback!