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]> wrote:
> > 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]> 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
