How is this different from prelink?
Clodl: Turn dynamically linked ELF binaries into self-contained closures
11–20 of 29 posts
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#12Earlier quoted context omitted.
when have you last tried to create a statically-linked binary that used glibc, and how did that go for you? or how about statically relinking a dynamically-linked binary you don't have sources for? (but hey, I also felt cheated when I read how clodl works. the hope for magic is always there, isn't it)
> when have you last tried to create a statically-linked binary that used glibc, and how did that go for you? I don't write code that requires Glib, but last I remember, there are explicit (lesser-known) flags that give complete static independence :P My implicit point is that essentially, there is a slew of approaches that seem to be reinventing the wheel to solve the obvious problems in dynamic linking, but they se…
>Because people have the memoized knowledge that "static linking old and bad",
It feels to me that the container mentality wants to abstract the complexity of the computing to the point they are creating issues that were solved before then layering that on a complex OS and pretending the OS isnt required |
At some point software has to sit on hardware...
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#13That is, given a shared library or a position independent executable (PIE), it returns a single, self-contained file packing all dependencies. [...] but closures do allow for deploying to other machines without concerns about missing dependencies. So. It's a statically linked binary, but worse? Or like a PAR file, but for C? I'm really not sure what the benefits are here over statically linked binaries. In fact, sinc…
Pretty please, tell me how to compile static binaries and I’ll do that forever. I always end up with certain external libraries still being required.
You need to compile a static executable (not with static libraries, there's a subtle difference). The flags depend on your compiler.
If you're on Linux, musl libc and musl-tools are useful for dealing with this reliably.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#14How is this different from prelink? https://linux.die.net/man/8/prelink
Prelinking just attempts to fix up load addresses so there are no conflicts at runtime that require relocations; it doesn’t bundle the libraries and as such solves a fundamentally different problem.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#15Nix can do this for basically anything - even python scripts with all their dependency modules, binary extensions and all dynamic lib dependencies, packed up into a single .nar file.
nix-shell can even be used as a shebang-line for scripts: https://nixos.org/manual/nix/stable/#use-as-a-interpreter
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#16That is, given a shared library or a position independent executable (PIE), it returns a single, self-contained file packing all dependencies. [...] but closures do allow for deploying to other machines without concerns about missing dependencies. So. It's a statically linked binary, but worse? Or like a PAR file, but for C? I'm really not sure what the benefits are here over statically linked binaries. In fact, sinc…
Pretty please, tell me how to compile static binaries and I’ll do that forever. I always end up with certain external libraries still being required.
Use Cosmopolitan Libc. Everything is statically linked. See for example https://justine.lol/redbean/index.html don't you want binaries like that?
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#17Author should consider using Actually Portable Executable for the bootstrapper.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#18Earlier quoted context omitted.
Pretty please, tell me how to compile static binaries and I’ll do that forever. I always end up with certain external libraries still being required.
You need to compile a static executable (not with static libraries, there's a subtle difference). The flags depend on your compiler. If you're on Linux, musl libc and musl-tools are useful for dealing with this reliably.
> You need to compile a static executable
This is functionally impossible on $ISA-linux-gnu, because the glibc developers refuse to provide a working C standard library (libc.a).
> musl libc and musl-tools are useful
Sure, but if the software worked (/reliably) with musl, we'd be using that already.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#19Nix can do this for basically anything - even python scripts with all their dependency modules, binary extensions and all dynamic lib dependencies, packed up into a single .nar file. nix-shell can even be used as a shebang-line for scripts: https://nixos.org/manual/nix/stable/#use-as-a-interpreter
On the other hand, Nix is also the only Linux distribution to have broken ("changed") the LD_LIBRARY_PATH behavior of the runtime linker, which means 3rd party "self-contained" packages can't work there, even though they do on every other Linux distro.
So there's that.
Re: Clodl: Turn dynamically linked ELF binaries into self-contained closures
#20Earlier quoted context omitted.
when have you last tried to create a statically-linked binary that used glibc, and how did that go for you? or how about statically relinking a dynamically-linked binary you don't have sources for? (but hey, I also felt cheated when I read how clodl works. the hope for magic is always there, isn't it)
> when have you last tried to create a statically-linked binary that used glibc, and how did that go for you? I don't write code that requires Glib, but last I remember, there are explicit (lesser-known) flags that give complete static independence :P My implicit point is that essentially, there is a slew of approaches that seem to be reinventing the wheel to solve the obvious problems in dynamic linking, but they se…
[deleted]