== Go 1.16 will make system calls through libc on OpenBSD One of the unusual things about [[Go https://golang.org/]] is that it started out with the approach of directly making system calls on Unix, instead of calling the standard C library functions that correspond to those system calls. [[There are reasonably good reasons for Go to make direct system calls GoCLibraryAPIIssues]] and this works well on Linux, but other Unixes are different. The official API for Illumos and Solaris system calls requires you to use their C library, and OpenBSD wants you to do this as well for security reasons (for [[OpenBSD system call origin verification https://lwn.net/Articles/806776/]]). Go has used the C library on Solaris and Illumos for a long time, but through Go 1.15 it made direct system calls on OpenBSD and so current released versions of OpenBSD had a special exemption from their system call origin verification because of it. The news of the time interval for Go 1.16 is that this is changing. To quote from the current draft release notes (which are probably soon to be the official release notes): > On the 64-bit x86 and 64-bit ARM architectures on OpenBSD (the > _openbsd/amd64_ and _openbsd/arm64_ ports), system calls are now > made through _libc_, instead of directly using the _SYSCALL/SVC_ > instruction. This ensures forward-compatibility with future versions > of OpenBSD. In particular, OpenBSD 6.9 onwards will require system > calls to be made through _libc_ for non-static Go binaries. As far as I know, Go programs that look up host names or do a few other operations are very likely to not be statically linked. You can force static linking (and you'll normally get it if you cross-build), but it has some drawbacks for hostname lookups in some configurations and you can't do some other operations at all. At one level everything is okay with this situation. OpenBSD 6.9 will almost certainly include Go 1.16 in its ports collection, since it will be the only version of Go that works on it, and from there you can build Go programs that will run fine on 6.9. At another level, any dynamically linked Go program you have will need to be rebuilt with Go 1.16 before you can run it on OpenBSD 6.9. Hopefully you have the source code and can still build it (in what will be a 'modular by default' world in Go 1.16). This is nothing really new for OpenBSD, which has always made it clear that they don't promise ABI or even API compatibility; you always need to be prepared to rebuild your programs for new OpenBSD versions, and perhaps to update them to more secure APIs. (Statically linked Go programs built by Go 1.15 or earlier will likely keep working on OpenBSD 6.9, assuming that there are no other ABI changes that affect them. But you should probably plan to rebuild them with Go 1.16 just to be sure. I don't know what the situation will be if you want to create Go binaries that work across a range of OpenBSD versions.) As the release notes say, Go 1.16 will make system calls through libc for all programs, whether they're dynamically linked or statically linked. Right now OpenBSD only requires this for dynamically linked programs (well, will require it), but always calling via libc is simpler than to maintain two sets of system call code. And someday OpenBSD may do something more elaborate so that making system calls via libc is required even for statically linked programs.