Moving beyond fork() + exec()

Re:Moving beyond fork() + exec() by purkka on Saturday June 06, 2026 @04:47PM (#48428860)

Nope, the kernel can load static ELF binaries. ld.so is only needed for dynamically linked binaries, and in fact many Go applications (for example, as they're statically linked) ship as containers with nothing but the single binary.

[ Parent | on HN ]

Re:Moving beyond fork() + exec() by dcrazy on Saturday June 06, 2026 @05:15PM (#48429077)

Thanks. I completely forgot about static binaries.

[ Parent | on HN ]

Re:Moving beyond fork() + exec() by loeg on Saturday June 06, 2026 @05:30PM (#48429183)

Of course ld-linux itself is an ELF binary. The kernel loads it.

[ Parent | on HN ]

Re:Moving beyond fork() + exec() by bregma on Sunday June 07, 2026 @07:22AM (#48433785)

Not only is it an ELF binary, but it is ironically a static ELF binary.

[ Parent | on HN ]

Re:Moving beyond fork() + exec() by krackers on Sunday June 07, 2026 @01:37AM (#48432147)

You can do this on macOS too, if you're willing to break all forward/backward compatibility and make direct syscalls you can have a purely static binary. Without the LC_LOAD_DYLINKER command on the mach-o binary the kernel should just jump to the entrypoint based on LC_UNIXTHREAD. (This may not longer work on arm machines though if they actually trap on direct syscalls not through libSystem, similar to the BSDs)

[ Parent | on HN ]