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