4 ms·
This has probably been the case since Go 1.11 (2018/08/24)[0] On macOS and iOS, the runtime now uses libSystem.dylib instead of calling the kernel dire
by terinjokes 7y ago
This has probably been the case since Go 1.11 (2018/08/24)[0]
On macOS and iOS, the runtime now uses libSystem.dylib
instead of calling the kernel directly. This should make
Go binaries more compatible with future versions of
macOS and iOS. The syscall package still makes direct
system calls; fixing this is planned for a
future release.
I'm not an expert in Darwin, but looking at the implementation of the syscall and runtime packages in Go 1.13, and most seem to be via trampolines into libSystem.dylib
FreeBSD looks deprecated not because of syscall difficulties, but because missing functionality and upstream EOL.[1]
[0]: https://golang.org/doc/go1.11#runtime https://golang.org/doc/go1.11#runtime
[1]: https://github.com/golang/go/issues/27619 https://github.com/golang/go/issues/27619
- int_19h 7y agoFair enough - so it's fixed on macOS, but not on FreeBSD. That they don't run into issues with this constantly on BSD is not surprising - it didn't always break in macOS, either. Syscalls just don't change that much, usually, so you can get away with it more often than not. The problem is that when they do change eventually, every precompiled Go app that used one stops working.