I’m confused. Are you saying that the studies being done and showing positive results should just be ignored? Why are these studies viewed as wishful thinking?
As a one man software consultant, I just want to point out that you are working with clients, in their systems, on their problems. You provide advice, they make the decisions they deem best for their company.
You get to choose the problem spaces and teams, which is a degree of autonomy. But it is not quite so free as “making your own decisions and not answering to anybody.”
The point I am making is that crt0.o usually comes from libc, even if it is linked separately.
I suspect that the loader expects the ELF entry point to be an address in the application, not a dynamically linked library, which is why crt0.o must be statically linked.
It says "usually". It varies! But, in general, the libc implementations I have looked at handle this. This includes Newlib, glibc (they call it start.s), picolibc, musl (crt1), and my own libc.
The presence in your binary only means that crt0.o was statically linked (may be an expectation of the loader on your system). If you linked against a static libc, you would also see those symbols as part of the binary.
Thanks for commenting. I had read your article via another comment here. I had not thought about the syscall approach before, because as you note Apple does not (well, did not previously) guarantee syscall stability.
Thanks. It is a clever approach. But at best all I can do is amend the original statement to "only dynamically linked applications are supported". Apple does not guarantee syscall stability (as is evident by Go's big break, and eventual move to libSystem).
Please provide a source for a statically linked application on MacOS, Intel or otherwise. When I wrote this article, Apple's own documentation said it was not supported. libSystem is also only provided as a dynamic library.