Update CentOS 7 to Golang 1.6

wowCentOS 7 is a rock-solid development and production platform, but this stability often means that default web-related packages are outdated. It turns out golang is no exception: the default CentOS 7 version is 1.4, whereas I wanted 1.6. There have been some changes in golang project layout between the two versions and I figured I may as well get with the program and update before starting a new API project.

There wasn’t much trace of updated RPM packages in the usual trusted locations, so things looked a bit grim initially. I guess I might have considered a build from source for a key member of the toolchain if all else failed, but thankfully a workable non-RPM update solution proved clean and simple enough. Some digging around on the golang site revealed that up-to-date tarball binaries are available there for download right alongside the source code:


Installation is simple and goes something like this for a local (ie not system-wide) installation:

Download the binary tar.gz package to a directory such as $HOME/bin/:

cd $HOME/bin
wget https://storage.googleapis.com/golang/go1.6.linux-amd64.tar.gz

Unpack the package. The resulting directory automatically renames itself to go:

tar xzvf go1.6.linux-amd64.tar.gz

In $HOME/.bash_profile, export the environment variable $GOROOT:

export GOROOT "$HOME/bin/go"

Add this path to your main $PATH variable:

export PATH=$PATH:$GOROOT/bin

Older versions of golang already installed via RPM or otherwise will of course need to be removed before running the new version.

For a system-wide installation, simply unpack the binary to /usr/local/go. Because go expects to be located here by default it is not necessary to set the $GOROOT variable, but it is still necessary to add /usr/local/go/bin to the $PATH environment variable. To do so, add the following line to either /etc/profile (for a system-wide installation) or $HOME/.bash_profile:

export PATH=$PATH:/usr/local/go/bin


A final word on setting the $GOROOT variable: Golang guru Dave Cheney pointed out some time ago that setting this variable is normally unnecessary, and can actually cause problems in some situations. One of the few situations where it is still necessary is the one described here … installing a tarball binary to a custom location on Linux. Indeed, my install didn’t work properly until this variable was set.