| 1 |
On Thu, 2019-09-12 at 13:38 -0700, Alec Warner wrote: |
| 2 |
> On Thu, Sep 12, 2019 at 1:20 PM Kent Fredric <kentnl@g.o> wrote: |
| 3 |
> |
| 4 |
> > On Wed, 11 Sep 2019 17:28:22 -0700 |
| 5 |
> > Alec Warner <antarus@g.o> wrote: |
| 6 |
> > |
| 7 |
> > > I don't care if you strip or not (I'm not even sure portage knows how to |
| 8 |
> > do |
| 9 |
> > > it for go binaries) but I'm fairly sure the reason isn't because |
| 10 |
> > "upstream |
| 11 |
> > > does not support stripping go binaries" because they clearly do...unless |
| 12 |
> > > upstream is portage here...? |
| 13 |
> > |
| 14 |
> > I know rust at least has some sort of magic in place where if you do |
| 15 |
> > strip a binary, the ability for it to produce useful stack traces when |
| 16 |
> > it crashes is reduced. |
| 17 |
> > ( In that, it can make use of debugging symbols without the aid of a |
| 18 |
> > debugger ) |
| 19 |
> > |
| 20 |
> > I can imagine that could be a reason to not support it. |
| 21 |
> > |
| 22 |
> |
| 23 |
> You definitely should not call 'strip' on a go binary. If you build with |
| 24 |
> the aforementioned linker flags you still get proper panic backtraces, but |
| 25 |
> also smaller binaries that you cannot load into gdb. Why 'strip' can't do |
| 26 |
> this but the go compiler can seems to be a bug ;) |
| 27 |
> |
| 28 |
|
| 29 |
Since when it is a bug that when you strip debug info, you don't have |
| 30 |
debug info? I thought that's precisely what stripping debug info means |
| 31 |
but maybe in the special Go world it is different, and debug info is |
| 32 |
expected to remain after stripping it. |
| 33 |
|
| 34 |
-- |
| 35 |
Best regards, |
| 36 |
Michał Górny |
Archives