Clodl: Turn dynamically linked ELF binaries into self-contained closures

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.

How useful is that though, for liberating and expropriating binaries? That things got to be at least several megabytes. If I used that as an interpreter or shell script prefix hack then I'd feel like an ant riding on the JVM's coattails.

That's one of the reasons I wrote APE. The bootloader shell script prefix is only 12kb so you can write a small program and it'll feel like it's actually your program. When you distribute it to your friends (respecting their time not asking them to become build system experts, just to try the cool thing you've written) you'll find that APE lets it run on seven operating systems too and most importantly, it'll just feel like something you've written, and that is yours, rather than, "hey grandma install oracle java first, here's how to remove the toolbar" kind of things where you're just evangelizing someone else's platform.

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)

My guess is that the benefit is they can write their applications in Haskell, package up the binary into a JVM application/shim (which can be templated in a bazel macro) and deploy a service into something like AWS Lambda or existing infrastructure for their clients. They're a consultancy that favors Haskell https://www.tweag.io/services

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.

It can be tricky to get static executables out of a complex build process that wasn't put together with that goal in mind.

For reasons, I was trying to do that for a while, but it was easier for me to bundle a dynamic exe with the dependencies (including an appropriate dynamic linker) rather than continue to fight with complex makefiles. Without looking at the code, it seems like this ended up similarly.

I often work on static linking with Nix.

Creating statically linked end user programs that aren't minimal CLI utilities is not trivial.

You need static linking working for all your dependencies (`.a` files) of all your recursive dependencies (hundreds of C libraries, and often up to hundreds of libraries in the higher-level language you may be using).

You need to either use a very configurable package distribution like nixpkgs, or a distribution that specialises in static Linking like Alpine Linux.

These toolchains now make static linking possible and much easier, and nixpkgs can build hundreds of C and Haskell programs statically. Go is also easy. When you can statically link, it is often better, but there are still many programs for which it doesn't work yet, and just "packing up all the .so files" as proposed in the announcement is certainly easier.

For people who want to contribute to static linking, consider contributing to nixpkgs/NixOS and Alpine Linux.

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.