cmd/go: go install -ldflags should always rebuild

[natefinch]

Please answer these questions before submitting your issue. Thanks!

What did you do?

go get github.com/foo/bar
go install -ldflags=-X = github.com/<some valid variable path>
// check that variables were set in the binary

What did you expect to see?

binary created in $GOPATH/bin with appropriate values set

What did you see instead?

go install short circuited and didn't rebuild because the packages hadn't changed.

Does this issue reproduce with the latest release (go1.9.2)?

yes

System details

go version go1.9 darwin/amd64
GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/finchnat"
GORACE=""
GOROOT="/Users/finchnat/src/github.com/golang/go"
GOTOOLDIR="/Users/finchnat/src/github.com/golang/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/ch/4d1vgsv17jq0b3yfmnkl9thdk0jm7d/T/go-build252358238=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOROOT/bin/go version: go version go1.9 darwin/amd64
GOROOT/bin/go tool compile -V: compile version go1.9
uname -v: Darwin Kernel Version 16.7.0: Thu Jun 15 17:36:27 PDT 2017; root:xnu-3789.70.16~2/RELEASE_X86_64
ProductName:	Mac OS X
ProductVersion:	10.12.6
BuildVersion:	16G29
lldb --version: lldb-900.0.50.1
  Swift-4.0

Thoughts

This is related to #22469

I have a command build with go that has a build script that uses ldflags to set the version, commit hash, etc. Standard stuff.

However, if someone uses go get to get my command, and then runs the build script (which just calls go install -ldflags with the right flags.... then nothing happens.

go install should not short circuit the build if you pass in ldflags, because by definition, the new binary will be different than the old one (ok, possibly it'll be the same as the old one, but go install can't know that).

[ianlancetaylor]

I believe @rsc already intends to fix this for 1.10, but I couldn't find a different bug for it.

[mvdan]

Isn't this #18369?

[ianlancetaylor]

Yes, thanks @mvdan, closing as dup.