3 ms·

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?

by Macha 5y ago

flohofwoe 5y ago
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.
- onei 5y ago
  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.
  - ptsneves 5y ago
    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.
  - ghoward 5y ago
    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 https://thephd.dev/intmax_t-hell-c++-c
patrakov 5y ago
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.
- Someone 5y ago
  https://lwn.net/Articles/806776/ 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 https://golang.org/doc/go1.11#runtime, that’s fairly recent (since go 1.11)

3 ms·

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?

by Macha 5y ago

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?

flohofwoe 5y ago
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.
- onei 5y ago
  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.
  - ptsneves 5y ago
    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.
  - ghoward 5y ago
    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 https://thephd.dev/intmax_t-hell-c++-c
patrakov 5y ago
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.
- Someone 5y ago
  https://lwn.net/Articles/806776/ 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 https://golang.org/doc/go1.11#runtime, that’s fairly recent (since go 1.11)