Linux kernel will support $ORIGIN, sort of

I was confused on what $ORIGIN means, so, macroexpanding the article a bit

https://fzakaria.com/2026/06/21/nix-needs-relocatable-binari...

> The loader in Linux however natively supports the variable $ORIGIN which translates to “the directory containing the executable.”

https://man7.org/linux/man-pages/man8/ld.so.8.html

But, if ld.so supports $ORIGIN already, why does the kernel needs to support it also? Or rather, why can't the kernel leverage ld.so and do this entirely on userspace?

My reaction was negative when I read the title (policy!), but the actual outcome was very reasonable. "Hey, can we add $ORIGIN to the VFS layer to support relocatable interpreters?" "You can already do that with binfmt_misc and ebpf, here's an example."

Then, later, a couple of patches to make binfmt_misc more ergonomic. Seems like a good outcome.

Many people here seem to think this change will allow for people to package their Linux apps to be portable across distros/distro releases. If this is true then this a great!

On Debian-based distros it kind of sucks when the version of a package is only available in a newer release so the only way to get it is either compile it yourself or upgrade your system.

I remember trying to hack around this once by downloading dependencies from a newer release and helping the program locate them but I think I ran into a issue with the linker version being hardcoded or something and gave up.

Nice, PT_INTERP is the only non-relocatable thing of ELF files and typically requires wrapper scripts/executables.

Regarding shebangs, I've never understood why the kernel cannot resolve e.g. `#!sh` relative to PATH instead of CWD. Posix prescribes that you should look for `sh` in PATH and don't expect it to be in `/bin/sh`. And using `/usr/bin/env sh` has the same issue: what if coreutils is installed elsewhere.

Wait, does this mean we can „virtualize“ ld.so now? This could finally solve the compatibility issues glibc causes.

I wonder if something equivalent exists for loading other kinds of assets. Take files that would normally live under `/usr/share`. References to these files are typically hardcoded with an absolute path as well. It's usually possible to relocate them at build time by specifying a different absolute prefix, but making them relative the conventional way would likely require patching.

Nix has caused so much busywork to be created through the entire Linux ecosystem. Rather than fixing their own project they force work upon so many others.

Instead of looking for ways Nix could work with ensuring else they force everything else to be modified to work with Nix. You will constantly seem them trying to get projects to adapt a flake.nix or to replace bash scripts with a different shebang since they hardcode a single binary that is rare for people to use in the real world.

This is really awesome, can't wait for this to land in the linux kernel.

I have made appseed[0] (asciinema link[1]) which used zapps[2] which did a lot of tricks to achieve in end what this kernel patch could help in doing and hopefully more in the future!

My appseed project didn't work for large projects like OBS but I feel like the approach that this does could lead to mass adoption given that its now a kernel feature. It could in theory allow more portable binaries across Linux which is really cool :)

[0]: https://github.com/SerJaimeLannister/appseed

[1]: https://asciinema.org/a/zK0T3WXAxalMYCVUY1vp8FAv3

[2]: https://zapps.app/

linux ELF code is loading the ELF loader only. $ORIGIN may not be a good idea since that would add more ELF complexity to the kernel.

If we are honest with ourself, ELF is the core of the issue: for executables and dynamic libraries we _now_ know it is severely obsolete on modern hardware architectures.

I am currently using my own format, excrutiatingly simple, no loader, basically a program segment, "userland syscalls" with hardware CPU synchronization. I do wrap the executables into ELF capsules to run them transparently. So simple a small RFC will be enough.

With that, I discovered that the hard part is c++ and other similar languages which are very expensive in runtime infrastructure and linking complexity. I would need to build a mesa vulkan driver with that format, and it seems the blocker is c++ (and similar language namely with grotesque and absurd syntax complexity). Thx to valve to have removed a lot of c++, for less c++... would have been much better if plain and simple C.

The correct fix is to store the metadata outside the CAS, in for example, the loader, which can trivially delegate to another loader (does on my machine now).

bazel's wrong solution is $ORIGIN, Nix's wrong solution is "floating" CA / "realizations".

The technical debt / precedent argument doesn't apply: Nix never had this bug (for once), you the choices on this bug are 1. port the bazel bug to Nix 2. don't port the bug.

I predict... the bug is a shoe in, the bug lands eight days a week.