3) I’d like to build with the standard Go compiler instead of gccgo. I currently have this in Build-Depends in the control file:
Build-Depends: debhelper (>= 11),
dh-golang,
golang-any,
…
Should I just replace golang-any with golang-go, or is it preferred that we actually support gccgo?
What’s your motivation to do so? Definitely leave a comment if you go that route. Also, note that this will mean that your package will be available on fewer architectures (some are supported by gccgo, but not by gc).
The irtt server that’s compiled with gccgo (amd64) can exit for no reason, and it doesn’t leave a log message, but there's no code path by which that should even be possible. It's easier to switch to a compiler I know than try to track it down. It can take a few days to reproduce. :)
You do realize that golang-any gets you the gc compiler on architectures that support it? Switching from golang-any to golang-go changes nothing on amd64.
I do not. :) My assumption that gccgo is used was based on the fact that after I install it there are .gnu_version sections in the binary that are not in a binary compiled with gc 1.11.5:
$ objdump -x /usr/bin/irtt
6 .gnu.version 0000004c 00000000005e1de0 00000000005e1de0 001e1de0 2**1
CONTENTS, ALLOC, LOAD, READONLY, DATA
But perhaps these are there for some other reason, like the fact that the binary uses dynamic linking, which is another difference from the binaries I usually test with:
$ readelf -d /usr/bin/irtt
Dynamic section at offset 0x298120 contains 19 entries:
Is there a way to definitively tell which compiler was used when it wasn’t built for debug? Or more importantly, any ideas how to go about solving the actual problem?