More or less what versions of Go support what OpenBSD releases (as of March 2020)
In light of recent entries, such as the situation with Go on OpenBSD, I've decided to write down what I can find out about what versions of Go theoretically work on what releases of OpenBSD. This is not actually tested for various reasons including the lack of suitable OpenBSD machines (for example, ones that are not in production use as important firewalls).
The Go people have a wiki page on OpenBSD that lists both the Go versions in OpenBSD's ports tree and the built from source versions that are supported on various OpenBSD releases. Additional information comes from the Go release notes for major versions; the release notes are potentially more accurate than the wiki, especially for old OpenBSD releases.
Going through both sources, I believe it breaks down this way for 32 and 64-bit x86:
- OpenBSD 5.0 through 5.4 is supported by Go 1.1 and Go 1.2 only
(the wiki seems to say it's supported by Go 1.0, but the Go 1.1
release notes specifically mention that OpenBSD support is new in it).
- OpenBSD 5.5 requires at least Go 1.3 and last supports Go 1.6 or
Go 1.7, depending on who you believe. The wiki says Go 1.7, but
the Go 1.7 release notes
say that it requires OpenBSD 5.6 or better because it uses the
- OpenBSD 5.6 through 6.0 requires at least Go 1.4.1 due to at least
issue #9102. You might
be able to use Go 1.3 if you don't use
net.Interface, but I'm not sure. OpenBSD 5.8 is last supported in Go 1.7, OpenBSD 5.9 is last supported in Go 1.8, and OpenBSD 6.0 is last supported in Go 1.10.
OpenBSD 5.6 is the oldest version currently listed as having a version of Go in its ports tree.
- OpenBSD 5.9 is the oldest release supported by Go 1.8, from
the Go 1.8 release notes;
this is apparently due to using new syscalls that OpenBSD was
- OpenBSD 6.0 is the oldest release supported by Go 1.9, at least
for cgo binaries, per the release notes. It's possible that non-cgo
binaries from Go 1.9 would run on OpenBSD 5.9, but they won't run
on anything before that due to those syscall changes in Go 1.8.
- OpenBSD 6.1 requires at least Go 1.8 and is last supported by Go 1.10.
Since Go 1.4 is the last version of Go that can be built without an existing Go compiler and it doesn't run on 6.1, building Go on OpenBSD 6.1 (and later) requires either getting an initial version of Go from the OpenBSD ports tree (if you can still find an operable ports archive for your old OpenBSD release) or bootstrapping from cross-compiled source.
- OpenBSD 6.2 and 6.3 are listed as requiring at least Go 1.9 in
the wiki, but I can't find anything in the release notes about
why. The wiki claims that 6.2 and onward are still supported in
Go 1.14 (the current Go version as I write this).
OpenBSD 6.2 is also the oldest release supported by Go 1.11, per the release notes.
- OpenBSD 6.4 (and later) requires at least Go 1.11, due to a new OpenBSD kernel thing covered in CL 121657.
OpenBSD 6.5 and 6.6 have no additional Go version restrictions; they're supported by 1.11 onward through Go 1.14 (currently). These are the two releases that are currently supported by OpenBSD (as mentioned in the depths of the FAQ). In a few months, OpenBSD will likely release OpenBSD 6.7, at which point 6.7 and 6.6 will become the two supported releases and Go will only officially support them.
Generally it looks like if you can stick with OpenBSD 6.2 or better, you're theoretically fine for Go support and can use the latest Go version (and thus build programs that require it, are module based, and so on). OpenBSD 6.2 dates from October of 2017, so many people will be covered by this. A future version of Go may stop working on older OpenBSD versions (the next release of Go will likely only officially support OpenBSD 6.7 and 6.6), but so far there seems to be nothing that would force this.
We're an unusual case in our range of OpenBSD releases. Currently we have machines running OpenBSD 5.1, 5.3, 5.4, 5.8, 6.2, 6.4, and 6.6. If we tried to use Go on all of them, we would have to restrict ourselves to Go features from Go 1.2 and also maintain multiple Go versions across the various range of machines (and multiple compiled binaries for Go programs).