Ok, I see now that gccgo is not used for amd64 builds, though they are 
dynamically linked. That leaves the question why I’m seeing this problem with a 
binary that came from Ubuntu 18.04, and not with binaries I compile. I guess 
that’s for me to figure out. :) Thanks for the help…

https://buildd.debian.org/status/fetch.php?pkg=irtt&arch=amd64&ver=0.9.0-2%2Bb10&stamp=1548450975&raw=0

> On Feb 6, 2019, at 5:37 PM, Michael Stapelberg <[email protected]> wrote:
> 
> The build log should state it. Only one compiler will be installed.
> 
> On Wed, Feb 6, 2019 at 12:29 PM Pete Heist <[email protected] 
> <mailto:[email protected]>> wrote:
> 
>> On Feb 6, 2019, at 11:07 AM, Michael Hudson-Doyle 
>> <[email protected] <mailto:[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?
> 
> 
> -- 
> Best regards,
> Michael

Reply via email to