Hacker News Reader

Comment by eqvinox | Hacker News Reader

If you can figure out your own ELF loader, you can figure out how to build a partially static executable that doesn't need this. You can mix static and dynamic linking. Build tooling around that is just shit.

View on HN

In this scenario, I'll have to choose which libc I want to run. These won't be portable Linux binaries in the true sense of the word; I'll have to leave Alpine out, and possibly Android, which I don't want.

You don't strictly need to; you can write freestanding C, and use the Linux kernel directly.

Fair point - while it's certainly possible to make a decision per individual library elsewhere, libc is the one thing that really will need to be linked dynamically for glibc, and it'll freeze a minimum version into the binary (i.e. it should be built against an old version of glibc).

I don't think Android is a target in most cases of this, so this would boil down to shipping 2* binaries, one glibc and one musl.

I'd need to check how musl behaves for compatibility, I'm assuming it'll be a minimum like glibc.

All of this said - you'll need to ship multiple binaries anyway, these days: x86_64 + aarch64. Possibly more…

Can you really mix it? When I break or remove a shared lib, some binaries no longer work. With static libs or even better, e. g. statically compiled busybox, I don't have that issue, so I disagree on the claim that mixing solves everything as such. I keep the basic toolchain I use as statically compiled variant. The whole system works better if I can break it less easily.

I'm not sure that's particularly relevant; if I null out bits of the statically linked binary to remove some code paths, they break too.

Reply on news.ycombinator.com