Hacker News Reader

Comment by Macha | Hacker News Reader

Didn't Go have to throw in the towel on not dynamically linking libc on macOS as there's no guarantee of syscall stability at all?

View on HN

I don't know about macOS, but they also did this on OpenBSD. The reason is a recent security addition in OpenBSD, where they made it illegal (as in: violate it, and the process will be killed) to issue syscalls to the kernel from anything other than libc.

https://lwn.net/Articles/806776/ discusses that feature and says “Switching Go to use the libc wrappers (as is already done on Solaris and macOS)”, so yes, they did that on macOS, too.

Reading https://golang.org/doc/go1.11#runtime, that’s fairly recent (since go 1.11)

Don't know, I only know that I can build a macOS command line tool on one machine, and run it on a different machine without problems, while on Linux it's very easy to run into the glibc version compatibility problem.

I always understood the glibc versioning problem to be solved by just building on the oldest common ancestor. If you have rhel5 through 8, you build on rhel5 and move on. If you depend on more than glibc... Well rhel5 is less fun.

Indeed, the only difference is that you might be using less optimal system calls, but there is no reason to be blocked and not target ancient kernels. I linked to 2.6 this year and everything ran fine.

Author here.

Unfortunately, building on the oldest common ancestor will still not save you from ABI breaks. An example is [1]. If the size of `intmax_t` changes between that oldest ancestor and the machines you are running on, get ready for pain.

[1]: https://thephd.dev/intmax_t-hell-c++-c

Reply on news.ycombinator.com