Last I checked, GDB is pretty much broken on macOS because it frequently hangs when launching processes. However, it did a decent job of reading in debugging symbols in the rare cases where it did work.
Regards, Saagar Jha > On Feb 17, 2019, at 00:57, René J.V. Bertin <[email protected]> wrote: > > Hi, > > How appropriate is the note attached to port:binutils nowadays? > > I installed it recently to test GNU ar in combination with software that > tries to use MRI scripts to generate and modify static libraries. A priori > every command is prefixed and I haven't noticed any problems with other ports > ... yet. > If there are known problems with certain components, why not put installation > of those in a variant? /methinks that it can't hurt to have "standard" > versions of utilities like ar... > > The port does conflict with port:gdb, something I had already observed in my > Linux adaptations of the two, something I solved in port:gdb with a somewhat > hard-handed > > {{{ > # we install a certain number of files also installed by port:binutils. > # Avoid existential problems: delete our copy and require binutils so > # everything is complete. > depends_run-append \ > port:binutils > > post-destroot { > # remove items already installed by port:binutils > file delete -force ${destroot}${prefix}/share/locale > file delete -force ${destroot}${prefix}/share/info/bfd.info > file delete -force ${destroot}${prefix}/lib/libopcodes.la > file delete -force ${destroot}${prefix}/lib/libopcodes.a > file delete -force ${destroot}${prefix}/lib/libbfd.la > file delete -force ${destroot}${prefix}/lib/libbfd.a > file delete -force {*}[glob -directory ${destroot}${prefix}/include/ *.h] > } > }}} > > I haven't (yet) checked this on Mac because my experience with gdb (v7) is > that it only works with very simple software and won't detect symbols from > libraries (if they don't have the corresponding .dSYM resource installed > maybe). Has that improved? > > R.
