3 ms·
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
by eqvinox 1mo ago
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.
- pg83 1mo agoIn 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.
- dwattttt 1mo agoYou don't strictly need to; you can write freestanding C, and use the Linux kernel directly.
- eqvinox 1mo agoFair 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…
- shevy-java 1mo agoCan 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.
- dwattttt 1mo agoI'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.