Repository navigation
cmd/link: use libsystem_kernel.dylib or libSystem.dylib for syscalls on macOS #17490
Description
As I understand it, Go currently has its own syscall wrappers for Darwin. This is explicitly against what Apple recommends, precisely because they're not willing to commit to a particular syscall ABI. This leads to issues like #16570, and although we've been lucky in that things have generally been backward-compatible so far, there's no guarantee that it'll continue to happen. It doesn't seem inconceivable to me that we'd at some point end up having to specify "build for macOS 10.13+" vs. "build for 10.12 and below", for example.
Linking against libsystem_kernel.dylib (or the broader libSystem.dylib) would put Go back in line with Apple's recommendations for the platform, and the library is guaranteed to exist on all macOS boxes.
Apologies if this has been suggested before and people have already gone over good reasons not to do it, but I'm currently struggling to figure out what appears to be another Sierra incompatibility related to #16570 above (still haven't figured it out enough to post a reproducible bug) and am wishing we didn't have to deal with these issues.
Activity
[-]Consider linking against libsystem_kernel.dylib or libSystem.dylib on macOS?[/-][+]cmd/link: link against libsystem_kernel.dylib or libSystem.dylib on macOS[/+]ianlancetaylor commentedon Oct 18, 2016
I agree that we have to do this. I'm not sure who is actually going to do it, though.
quentinmit commentedon Oct 18, 2016
Note that the trouble with #16570 comes from fetching the current time, and that is something that is so performance critical that we might want to continue to use our own implementation even if we use libSystem for other syscall.
crawshaw commentedon Oct 18, 2016
We got into a discussion about how to do this over on #17200. I believe this can be done without forcing external linking. But I also don't know who is going to do it, my plate is full for the foreseeable future.
rsc commentedon Jan 4, 2017
Agree we should do this at some point. It's not terribly high priority though.
[-]cmd/link: link against libsystem_kernel.dylib or libSystem.dylib on macOS[/-][+]cmd/link: use libsystem_kernel.dylib or libSystem.dylib for syscalls on macOS[/+]rsc commentedon Mar 8, 2017
This is about using the system calls. We already link against libSystem.dylib when cgo is in use.
hirochachacha commentedon Jul 20, 2017
Hi, I made a CL for x86. https://go-review.googlesource.com/c/50290/
Could someone review it (after development cycle open) ?
If the overall design is OK, I'd like do something in go 1.10. Thank you.
gopherbot commentedon Jul 20, 2017
CL https://golang.org/cl/50290 mentions this issue.
52 remaining items
gopherbot commentedon Jan 6, 2019
Change https://golang.org/cl/156365 mentions this issue:
cmd: vendor x/sys/unix into the stdlibcmd: vendor x/sys/unix into the stdlib
darwin: use custom syscall pkg that uses libsystem
darwin: use custom syscall pkg that uses libsystem
darwin: use custom syscall pkg that uses libsystem
darwin: use custom syscall pkg that uses libsystem
gopherbot commentedon Sep 30, 2019
Change https://golang.org/cl/197938 mentions this issue:
runtime: fix darwin syscall performance regressionruntime: fix darwin syscall performance regression
gopherbot commentedon Oct 9, 2019
Change https://golang.org/cl/200103 mentions this issue:
[release-branch.go1.13] runtime: fix darwin syscall performance regression[release-branch.go1.13] runtime: fix darwin syscall performance regre…
gopherbot commentedon Apr 14, 2020
Change https://golang.org/cl/227037 mentions this issue:
crypto/x509: use Security.framework without cgo for roots on macOScrypto/x509: use Security.framework without cgo for roots on macOS