Hacker News Reader

Comment by asveikau | Hacker News Reader

It says _start (crt0.o) comes from libc. But note, if you run nm on a binary you can see _start is part of the binary, not libc.so.

View on HN

The "libc" is more than libc.so. Your system headers, for example, must be shipped with your libc, even though everything that would change if you replace them with something nonsensical would be in "your" binary, not in libc.so. libc functions don't stop coming from the libc if you statically link them.

A C runtime is often provided by the same project as the C standard library (the other viable option is to have it provided by the compiler project).

> Your system headers, for example, must be shipped with your libc,

Not all. Typically stdarg.h is not. On Linux, <sys/*> is not.

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.

I think your last paragraph is wrong. crt0.o is static even when linking to libc.so dynamically. The ELF format has something in the headers for an entry point which will point at _start in your own binary, not in libc.so.

I'm pretty sure it works that way on windows too, but they call the symbol mainCRTStartup or some such.

What, exactly, is wrong?

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.

Reply on news.ycombinator.com