> On Feb 6, 2019, at 11:07 AM, Michael Hudson-Doyle
> <[email protected]> wrote:
>
> On Wed, 6 Feb 2019 at 21:23, Pete Heist <[email protected]
> <mailto:[email protected]>> wrote:
>> 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?
