[nextaccountic]

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?

[dgrunwald]

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

[charcircuit]

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.

[roblabla]

Not with NixOS. ld.so is tied to a version of glibc, in ways that can be subtly incompatible. And nixos can have multiple glibc version installed on a single machine.

Besides, it allows for upgrades/downgrades to be done in a way that's much less error-prone.

[mort96]

"ld.so is tied to a version of glibc" is such a horrible GNUism.

[myrmidon]

Isn't that kinda to be expected if you want to provide dynamic loading functionality (dlopen)?

Is the windows situation really all that different/better (with GetProcAddress in kernel32.dll)?

[roblabla]

In theory, ld.so could provide a stable interface to its dynamic loading capabilities independently of glibc. Then glibc would not have to be updated in concert with ld.so. There's no inherent reason that glibc should be the library shipping a dynamic linker - we could easily be in a world where libld was developed independently from libc.

On Windows, things are less modular, so it's less of an issue. That said, there's also weird shenanigans when it comes to the CRT (which can be statically linked) vs ntdll (which provides the actual linker implementation), that can make certain niche features of the linker misbehave (delay loading in particular is weird).

[jcgl]

Not my area, but isn't it really only because glibc doesn't maintain stable interfaces across versions? If it did, you absolutely could use the same ld.so with different glibc versions. But it doesn't, so here we are.

[mort96]

The Windows situation is way different: every process is supposed to link against kernel32.dll, that's the public interface to the kernel. In Linux, glibc is just one of many C stdlib implementations, you can have many versions of glibc on the same system, etc.

[kazinator]

ld.so is a component of glibc!

  $ /lib64/ld-linux-x86-64.so.2
  /lib64/ld-linux-x86-64.so.2: missing program name
  Try '/lib64/ld-linux-x86-64.so.2 --help' for more information.
  !1!
  $ /lib64/ld-linux-x86-64.so.2 --version
  ld.so (GNU libc) stable release version 2.34.
  ^^^^^^^^^^^^^^^^
  Copyright (C) 2021 Free Software Foundation, Inc.
  This is free software; see the source for copying conditions.
  There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
  PARTICULAR PURPOSE.

[charcircuit]

>in ways that can be subtly incompatible

There is much more value to be had in making glibc properly backward compatible so you can have a single one that can be used with everything than trying to make it so that you can swap everything around, creating extra complexity and compatibility risks.

[dspillett]

> […] in making glibc properly backward compatible […]

You could only do that going forward though, and would be stuck, at least for a time, with the historic versions that still need extra handling. In an ideal world that wouldn't be needed, but in an ideal world you'd not need multiple versions of glibc at all so we aren't there.

Support in the kernel means that it will work even if applied to old packages that for some other reason need a held-back version of glibc. As mentioned elsewhere it also gives the feature to #! directives in scripts too.

[roblabla]

How is that more valuable? It comes with two big pitfalls:

- It would still not allow downgrades to work properly

- It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together

Meanwhile, having different ld.so has many good use-cases, like simplifying development of ld.so itself, allowing them to swapped during updates in ways that are safer, etc...

And the eBPF binfmt support is a rather simple, generic mechanism that is likely to have many other use-cases beyond ld.so. So it's overall a pretty good resolution to the issue?

[charcircuit]

>It would still not allow downgrades to work properly

If you really need this, then there are options like swapping the linker with an older version or making a hardcoded linker that now points to an older one.

>It would cause glibc/ld.so to have a harder time adding new features, as they now need to worry about incompatible versions being used together

Every language runtime has to care about not breaking compatibility with apps that have been released already. This is not a new or unique problem.

[HexDecOctBin]

Unfortunately, Glibc and loader are linked together intrinsically in the Linux ecosystem. So, if you want to be able to launch a program reliably, shipping your own loader and libc might actually be the only way.

[VorpalWay]

Glibc is backward compatible though, they even have symbol versioning to provide multiple versions of the same symbol. So as long as you have the same or a newer version of glibc (than what was built against) you should be good to go. And I don't remember hearing about breakages for this.

Other libraries on the system is far more hit and miss, but glibc is quite compatible.

The other way around is harder though, you can't take a program built against a newer glibc and run it on an older version. So you generally need to spin up a container with some LTS distro and build your binary in it if you want it to be maximally compatible. (However, zig apparently is able to deal with this by shipping a mapping between glibc versions and symbol versions and doing the linking themselves. You can even use zig to link rust code using cargo-zigbuild and get that benefit.)

But if you want to be maximally portable: static linking against musl. Though beware that many things are slower in musl, such as the allocator.

[HexDecOctBin]

Glibc is the opposite of backwards compatible. This thread I was a part of explains some issues faced in the past: https://news.ycombinator.com/item?id=47029789

[VorpalWay]

Reading the linked bug report about executable stacks they fixed it? So they did the right thing. I'm not saying there will never be bugs (no non-trivial software is bug free), but as long as those are handled correctly that seems reasonable to me.

[Joker_vD]

No, glibc isn't backwards compatible; I've had instances when the loader would refuse to load the executable because the installed glibc is too new for it.

[bonzini]

That's not supposed to happen. I would like to have more info.

[kazinator]

If I had to choose between 16 dockers, or 16 processes with different ld.so, guess what I'm choosing ...

[jz391]

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

[setheron]

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

[matheusmoreira]

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

[reinitctxoffset]

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.

[seanhunter]

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.

[reinitctxoffset]

The privileged path is already there. `/usr/bin/env` is no different from `/bin/bash`, `/bin/sh`, or any other ELF artifact at a known place. The argument is made, the argument is spurious. It is made in the other direction regarding the driver run path, just as religious, opposite ruling from purity court. No one even knows why, the trail goes cold in a mysterious 2012 commit about Mesa, it's literally a performance to bring the plane cargo back. Receipts for claim: #141803.

Disagreeing with you doesn't make something a rant. If it's not clear how deep my Nix expertise is I will demonstrate it to any level you like: I'm just as entitled to an opinion as you are and I would appreciate it if the nixpkgs community was a little less rude to anyone who disagrees with some dogma no matter their knowledge. The nixpkgs community is not regarded as healthy or friendly after an internecine faction war that split three ways twice, producing four implementations none of which work, and if that reputation is ever going to mend, it will be because less than every Nix person has precisely zero chill the nanosecond anyone disagrees with them about anything.

[seanhunter]

It's no different other than it's a layer of indirection which allows bash to change in a way that would not be possible if scripts directly referenced /bin/bash or /usr/bin/bash. The only thing you can't change is the /usr/bin/env binary itself but that's not something that changes very much if at all. On my nix box, bash is at /run/current-system/sw/bin/bash and "current-system" is a symlink to a particular build in /nix/store. So /usr/bin/env is creating a layer of indirection so if I rebuild the system, the previous version can be kept around and I can roll back instantly at the boot menu and it will roll everything back to a consistent package set. Now as I say, you could achieve this in other ways eg fs snapshots etc. But to say that the change doesn't give you anything is just very obviously wrong.

And you don't need to worry- it's perfectly obvious how deep your Nix expertise is.

[reinitctxoffset]

You've just used a personal attack to shout down someone who disagrees in good faith over a distinction you simultaneously describe in your own words as "something you could achieve other ways" (yeah, more than a little bit) referencing an artifact that "is a symlink", "on my nix box".

The only thing I attacked are named instances of regrettable community malfunctions stripped of anything personal to an individual that hurt both current users of Nix and people who might experiment with systems they can reason about, saw an interaction like this, and did something less painful with their day. Because my evident and sincere concern for the future of Nix is framed as stark disagreement over a few particularly sacred cows.

At least on `comp.lang.lisp` you got your middle finger alongside a worthwhile education:

"There are some things in life that you do not do if you want to be a moral being and feel proud of what you have accomplished."

- Erik Naggum