4 ms·
Not true. On Solaris (and Windows), and more recently in macOS as well we link with libc (or equivalent), and we can still cross compile from any system to thes
by 4ad 8y ago
Not true. On Solaris (and Windows), and more recently in macOS as well we link with libc (or equivalent), and we can still cross compile from any system to these systems. It's not a free lunch of course, doing raw system calls would be preferable, for many reasons.
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.
- matthewbauer 8y agoHow 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 :)
- 4ad 8y agoYou 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.
- matthewbauer 8y agoOk nice! In many ways it would be cool if apple had a stable interface for XNU like we do in Linux.
- int_19h 8y agoUnfortunately, 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...