On Thu, 2019-09-12 at 13:38 -0700, Alec Warner wrote: > On Thu, Sep 12, 2019 at 1:20 PM Kent Fredric <ken...@gentoo.org> wrote: > > > On Wed, 11 Sep 2019 17:28:22 -0700 > > Alec Warner <anta...@gentoo.org> wrote: > > > > > I don't care if you strip or not (I'm not even sure portage knows how to > > do > > > it for go binaries) but I'm fairly sure the reason isn't because > > "upstream > > > does not support stripping go binaries" because they clearly do...unless > > > upstream is portage here...? > > > > I know rust at least has some sort of magic in place where if you do > > strip a binary, the ability for it to produce useful stack traces when > > it crashes is reduced. > > ( In that, it can make use of debugging symbols without the aid of a > > debugger ) > > > > I can imagine that could be a reason to not support it. > > > > You definitely should not call 'strip' on a go binary. If you build with > the aforementioned linker flags you still get proper panic backtraces, but > also smaller binaries that you cannot load into gdb. Why 'strip' can't do > this but the go compiler can seems to be a bug ;) >
Since when it is a bug that when you strip debug info, you don't have debug info? I thought that's precisely what stripping debug info means but maybe in the special Go world it is different, and debug info is expected to remain after stripping it. -- Best regards, Michał Górny
signature.asc
Description: This is a digitally signed message part
