Aha, now I understand. I managed to reproduce the problem and the failure
was occurring while running go vet after the build target (which runs go
build on all our packages). Switching to go install to build the packages
cleared the problem right up.
On Thu, 15 Sep 2016 at 20:19 Dave Cheney wrote
e out of date (at
> best) or fail (at worse).
>
> Really, you want to use go install, just trust me on this, it'll make you
> go experience much better all round.
>
> On Friday, 16 September 2016 04:03:54 UTC+10, Tom Elliott wrote:
>>
>> Thanks for the quick response
Thanks for the quick response :)
Great to hear that the go tool is intended to catch this. The problem was
typically seen when running our default make target, which uses build for
the build itself, but has some sanity checking and code generation steps
first, with tools like glock, errcheck an
We've recently migrated from Go 1.6 to 1.7 within our engineering team, and
have been experiencing some binary compatibility issues (as is to be
expected) that have usually been corrected by emptying $GOPATH/pkg and
rebuilding - this was recommended but as is the case with manual steps,
people
