After upgrading Go, I want to recompile all the tools, how?

<p>I can&#39;t seem to find any information at all on this. New compiler versions fix bugs and so I want to recompile the tools I have in $GOPATH/bin but there&#39;s seemingly no way to do that easily.</p> <hr/>**评论：**<br/><br/>sauerbraten_: <pre><p>I&#39;m not 100% sure right now, but try <code>go get -u ./...</code> in <code>$GOPATH/src</code>, after <code>rm -r $GOPATH/bin</code>.</p></pre>joolzter: <pre><p>Nice one - that&#39;s awesome!</p></pre>ChristophBerger: <pre><p>That&#39;s a good idea, with a small caveat. If there are multiple projects in <code>$GOPATH/src</code> that install a binary with the same name, the last one that <code>go get</code> processes will win. (And this might not be the one you want.)</p></pre>rjik: <pre><p>If you&#39;d have Go binaries in $PATH but no sources locally - you could use gobin to update all of them.</p> <pre><code>go get github.com/rjeczalik/bin/cmd/gobin gobin # lists Go binaries gobin -u # updates them </code></pre> <p>Disclaimer: I&#39;m the author of the tool.</p></pre>ChristophBerger: <pre><p>Nice! But how does <code>gobin</code> determine the right source if there are multiple possible projects with the same name in <code>$GOPATH/src</code>? Like, e.g., <code>github.com/author1/mycmd</code> and <code>bitbucket.org/author2/mycmd</code>.</p></pre>rjik: <pre><p>It guesses the import path of your executable by reading import paths, that are compiled in the binary.</p> <p>Similarly to <a href="https://forum.golangbridge.org/t/your-best-shell-aliases/1335/12" rel="nofollow">https://forum.golangbridge.org/t/your-best-shell-aliases/1335/12</a>.</p></pre>ChristophBerger: <pre><p>Ah, that&#39;s the trick! Didn&#39;t know that Go binaries include source import paths.</p></pre>frou: <pre><p>In my experience, this action does not only yield the niceties of compiler bugfixes, but is actually essential for tools like <code>errcheck</code> to continue working. The errcheck executable is interested in GOROOT and seems to use a value baked into it at compilation time, and so will stop working if one&#39;s Go installation is updated to a new version rooted at a different path.</p></pre>epiris: <pre><p>I really dislike the trend of tools trying to create hacks for people without valid PATH, GOPATH, GOROOT etc. Or trying to be clever to detect when they are out of date or whatever reasoning.</p> <p>If you are a command on my system I expect to execute you only when you exist in my path. When I run you I expect you to obtain any runtime environment context from, wait for it, my environment. That is how unix works, don&#39;t be clever because it leads to very bad mistakes at worst, and annoyances at best.</p> <p>Another example is tools using their own logic for executing programs, like adding GOPATH/bin with precedence over PATH. No. don&#39;t do this. It might help a few people with bad configuration, but they are fighting a uphill battle and all you did is nudge them a single a step. Meanwhile adding WTF to anyone with a correctly configured system that relies on properly implemented tooling. </p> <p>Side rant, nothing to do with you :-)</p></pre>frou: <pre><blockquote> <p>When I run you I expect you to obtain any runtime environment context from, wait for it, my environment. That is how unix works, don&#39;t be clever because it leads to very bad mistakes at worst, and annoyances at best.</p> </blockquote> <p>I just looked at the code and in errcheck&#39;s case (via some /x/tools stuff and package runtime) it seems it will respect a GOROOT env var, but if that is not set[0] then it will fall back to the baked GOROOT[1]. I guess the alternatives in that case are to call out to <code>go env GOROOT</code> or just error out.</p> <p>[0] I believe conventional wisdom is that Go programmers shouldn&#39;t be feeling the need to set GOROOT.</p> <p>[1] The baked GOROOT being a toolchain-level concept so maybe not a decision the errcheck author explicitly made.</p></pre>epiris: <pre><p>The check env then fallback is perfectly fine with me, though I prefer failure over fallbacks like that.. at least when my env is setup properly things work. Thanks for looking into it!</p></pre>creack: <pre><p>I have this in my shell config (zsh), so upon go upgrade or simply when I got a new computer, I just run the function:</p> <pre><code>function update_go_tools() { packages=&#34; github.com/ajstarks/svgo/benchviz github.com/axw/gocov/gocov github.com/cespare/prettybench github.com/dougm/goflymake github.com/golang/lint/golint github.com/josharian/impl github.com/kisielk/errcheck github.com/kisielk/godepgraph github.com/nsf/gocode github.com/tools/godep github.com/rogpeppe/godef golang.org/x/tools/cmd/... &#34; echo $packages | while read pkg; do echo &#34;$pkg&#34; go get -u $pkg done } </code></pre></pre>idboehman: <pre><p>You could use a <a href="http://stackoverflow.com/questions/8880603/loop-through-array-of-strings-in-bash-script" rel="nofollow">Bash array</a> instead of a string to save from echoing and trimming new lines. </p></pre>smcquay: <pre><p><code>go install std</code>?</p> <p>Edit sorry I misread the question. This answer is only tangentially useful. </p></pre>earthboundkid: <pre><pre><code>cd $GOPATH go install ... </code></pre> <p>This will not re-download, but it will recompile what was previously downloaded.</p></pre>