Linux kernel will support $ORIGIN, sort of

https://fzakaria.com/2026/07/20/linux-kernel-will-support-origin-sort-of

by ingve • 2 days ago

90 74 2 days ago

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/

nextaccountic• 2 days ago

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?

jz391• 2 days ago

One point mentioned in the first link you included is support of $ORIGIN in #! scripts - that would need kernel support.

setheron5• 1 day ago

This also can be handled by binfmt_misc; I include a demo of it in a gist.

dgrunwald• 2 days ago

$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.

charcircuit7• 2 days ago

Each program having its own loader is an anti pattern. Such a requirement is overkill. You can have a single loader that supports everything on the system.

reinitctxoffset4• 2 days ago

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.

seanhunter2• 2 days ago

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.

matheusmoreira• 1 day ago

why can't the kernel leverage ld.so and do this entirely on userspace?

Because Linux is completely independent from its user space. There is no "the loader in Linux", it just happens that GNU wrote one and it's widely used.

reinitctxoffset4• 2 days ago

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.

stabbles3• 2 days ago

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.

pm215• 2 days ago

I suspect it's a mix of historical reasons (#! support was added pretty early, in 1980 or so, when the unix development philosophy I think tended quite strongly to "do the simple thing", and there wasn't so much variation in where you might put important binaries like the shell), plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does), plus vague worries about potentially accidentally breaking existing #! lines that used to work.

chuckadams• 2 days ago

plus the fact that the kernel doesn't know anything about PATH (it's only your shell that does)

glibc is what deals with PATH, not the shell. On Linux, it's execvp(3) in libc which is implemented in terms of execve(2) in the kernel, but POSIX doesn't make a distinction between syscalls and library functions, so a kernel could implement either or none directly.

inigyou2• 2 days ago

The kernel never looks at PATH, that's why. It's a shell construct.

mort963• 2 days ago

... and the question was: "Why doesn't the kernel look at PATH"

It's not a "shell construct" either, the standard execvp libc function looks at PATH.

charcircuit7• 2 days ago

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.

rcxdude• 2 days ago

Rather than fixing their own project they force work upon so many others.

Nix has put in a ton of work to make their project work, and the assumptions in the rest of the ecosystem have been fighting every step of the way. And I would argue they've been changing it for the better, considering that if you were to just 'try to make nix work' you'd probably mainly come to the conclusion that it was impossible to make work sensibly due to the huge number of places where hardcoded relationships have been baked in.

charcircuit7• 2 days ago

and the assumptions in the rest of the ecosystem have been fighting every step of the way

There is an arrogance in the way of thinking that when you see everyone breaking your arbitrary rules you think to yourself "there is no way my rules are at fault, it's everyone else's fault for breaking them."

due to the huge number of places where hardcoded relationships have been baked in.

And why are hardcoded relationships bad for developers or users of the operating system? "Because they break Nix" is not a good excuse. Plenty of other operating systems work just fine with such things hardcoded, I don't see developers complaining about these hardcoded things, and moving things around can only make things more confusing for the user.

To me it looks like Nix picked a poor design and instead of going back to the drawing board and trying to come up with a better design they have gone all in on trying to force their bad design to work.

How much work do you think iOS or Android spend on app packaging / installation per year. Despite having millions of more developers and billions of more users they spend orders of magnitude less than NixOS does.

Edit: I can't reply since I'm rate limited.

Debian already supports installing multiple php versions.

You can use the update-alternatives command to set which one is default for the php command.

Via your web server's config you can config which php version a site will use.

the8472• 1 day ago

Many of those assumptions are standards such as the filesystem hierarchy (granted, that's an xkcd 927 situation), nix is a bit of a special snowflake that breaks things in subtle ways (e.g. [0][1]) and needs workarounds in various places. Those workarounds are not necessarily onerous, but they would be unnecessary if it didn't deviate.

[0] https://github.com/NixOS/nixpkgs/issues/420513 [1] https://github.com/NixOS/nixpkgs/issues/94228

farfatched• 2 days ago

Nobody forces projects to accept changes that add support for various platforms, yet it's common that they do.

Nix is one such platform.

wzdd• 2 days ago

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.

Siyo2• 2 days ago

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.

aboardRat44• 1 day ago

You can always set "RESOURCE_PATH" and load your files from there.

Siyo2• 1 day ago

Sure, assuming this is your own software. The context of the article is on working towards a general approach to relocatable nix binaries so I don't think that's going to scale across nixpkgs.

Asmod4n2• 1 day ago

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

setheron5• 1 day ago

(author) YESSSSSSS

Asmod4n2• 1 day ago

it's finally the year of linux on the desktop! :)

sylware2• 1 day ago

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.

setheron5• 1 day ago

I would love to learn more about this; I'm deeply interested in replacing ELF with something either simpler or maybe leveraging sqlite for much of the functionality.

setheron5• 1 day ago

Feel free to email me! (author)

bobajeff• 1 day ago

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.

aboardRat44• 1 day ago

Many people here seem to think this change will allow for people to package their Linux apps to be portable across distros/distro releases.

There is no need to make binaries portable across the distros, because Linux is a source based OS. You can always just compile anything for your own system, just don't forget to submit the buildscript to the repo.

accelbred• 1 day ago

Its unfortunate that this is using eBPF and not cBPF. I'd want to enable this in a namespace using binfmt-misc's namespace support, but eBPF requires root.

Linux kernel will support $ORIGIN, sort of

Related Stories