Re:C library system-call wrappers, or the lack thereof
by matthewbauer on Wednesday November 14, 2018 @11:59AM
(#18451373)
How do you handle changes to the kernel? Can your binaries run on any macOS version or only the very latest? This sounds really cool but also super dangerous. Apple is not known for providing a stable ABI :)
Re:C library system-call wrappers, or the lack thereof
by 4ad on Wednesday November 14, 2018 @12:47PM
(#18451876)
You got it backwards, Go used to do raw system calls on macOS, and binaries were occasionally broken by kernel updates. Now Go uses libc on macOS, and binaries are forward compatible with future macOS versions just like any other C/C++/ObjC/swift program. OS X 10.10 (Yosemite) is the current minimum supported version.
Re:C library system-call wrappers, or the lack thereof
by int_19h on Wednesday November 14, 2018 @06:36PM
(#18455331)
Unfortunately, Go still insists on using syscalls on the BSDs, despite them not being a stable (between major releases) API there either.
I hope they're planning to fix that...
Re:C library system-call wrappers, or the lack thereof
by matthewbauer on Wednesday November 14, 2018 @02:35PM
(#18453084)
Ok nice! In many ways it would be cool if apple had a stable interface for XNU like we do in Linux.
I implemented support for this, for ELF, when I wrote the Solaris port. Other people have done it for PE and Mach-O. It is a fallacy to think that you need access to a shared library in order to link with it. That's only true for C toolchains that don't know better. For Go we have our own toolchain and it doesn't have such a restriction.
This is one of the points lost to the "why didn't you just use LLVM?" crowds. Our own toolchain allows us flexibility that simply doesn't exist with traditional toolchains.