Linux kernel will support $ORIGIN, sort of
fzakaria.com
Linux kernel will support $ORIGIN, sort of
1–10 of 78 posts
Re: Linux kernel will support $ORIGIN, sort of
#2This 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/
Re: Linux kernel will support $ORIGIN, sort of
#3I 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?
Re: Linux kernel will support $ORIGIN, sort of
#4I 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, w…
One point mentioned in the first link you included is support of $ORIGIN in #! scripts - that would need kernel support.
Re: Linux kernel will support $ORIGIN, sort of
#5The 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.
Re: Linux kernel will support $ORIGIN, sort of
#6Nice, 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.
Re: Linux kernel will support $ORIGIN, sort of
#7I 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, w…
$ORIGIN was only supported when the loader was looking for other dependencies.
The loader itself (field PT_INTERP) is loaded by the kernel. So prior to this change, every program must hardcode the absolute path to ld.so.
With support for an $ORIGIN-relative loader, each program could use its own copy of ld.so.
Re: Linux kernel will support $ORIGIN, sort of
#8I 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, w…
You have the right idea but the wrong specifics. The boundary you're alluding to isn't the kernel/userspace boundary, it's the `libc` boundary, which is admittedly privileged by convention if not by Ring 0.
On most Linux systems this is regrettably `glibc` (in a container where you get to choose everyone chooses the superior option of `musl`), on all Darwin systems this is `libstandard`.
This thread is more concerned with Linux, so you are probably dealing with `/lib64/ld-linux-x86-64.so.2`, which operates in userspace but is by convention and opacity quite clearly part of "the system".
The kernel modification is a much bigger, much weirder side effect of a weird Nix loyalty test around shebang lines in shell scripts, on which is has opted to be intentionally and violently incompatible with everything for no benefit other than incompatibility.
Re: Linux kernel will support $ORIGIN, sort of
#9I 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, w…
You have the right idea but the wrong specifics. The boundary you're alluding to isn't the kernel/userspace boundary, it's the `libc` boundary, which is admittedly privileged by convention if not by Ring 0. On most Linux systems this is regrettably `glibc` (in a container where you get to choose everyone chooses the superior option of `musl`), on all Darwin systems this is `libstandard`. This thread is more concerned…
That’s a weird rant which is manifestly false. On Nix the benefit you get from the incompatibility is the system can roll forward and back while it’s running so you can do big changes (eg updating or rolling back) the entire system without affecting running processes. You can also run groups of processes in isolation with different sets (or versions) of packages from the rest of the system.
It’s fair to argue about whether those things are really important or whether nix does this in the best way, but to claim that the only benefit is incompatibility is just obvious nonsense.
Re: Linux kernel will support $ORIGIN, sort of
#10Nix 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.