Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Linux kernel will support $ORIGIN, sort of

fzakaria.com

Post reply on HN
Print view View original

61–70 of 78 posts

Re: Linux kernel will support $ORIGIN, sort of

#61

Post by setheron »

setheron wrote: post #60
sylware wrote: post #43

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 syscal…

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.

Feel free to email me! (author)

Re: Linux kernel will support $ORIGIN, sort of

#62

Post by charcircuit »

roblabla wrote: post #19
charcircuit wrote: post #17

Earlier quoted context omitted.

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

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 ar…

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

Re: Linux kernel will support $ORIGIN, sort of

#63

Post by charcircuit »

roblabla wrote: post #22
charcircuit wrote: post #16

Earlier quoted context omitted.

>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 relationship…

> 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." It's not really arrogance - it's just a different way to design a system. NixOS wants a few things: 1. An input-addressed dependency system 2. Easy and robust rollback/upgrades 3. Different versions of softw…

I suggest you take a look at Fedora Silverblue. It accomplishes all 3 of those goals.

Re: Linux kernel will support $ORIGIN, sort of

#65

Post by kazinator »

charcircuit wrote: post #13
dgrunwald wrote: post #7

Earlier quoted context omitted.

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

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.

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

Re: Linux kernel will support $ORIGIN, sort of

#66

Post by kazinator »

mort96 wrote: post #25
roblabla wrote: post #14

Earlier quoted context omitted.

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.

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

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.

Re: Linux kernel will support $ORIGIN, sort of

#67

Post by kazinator »

roblabla wrote: post #40
myrmidon wrote: post #31

Earlier quoted context omitted.

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)?

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, ther…

In practice, ld.so is a piece of glibc. If you want to build ld.so from scratch, you have to clone glibc or get a tarball of glibc, and configure and build glibc.

You could make the argument that the glibc developers should split ld.so into its own subprojects. What for? That would just bring the extra responsibility of making sure that variations in glibc version work with variations in ld.so version for whatever reason.

What would happen in practice is that they would keep their version numbers in lock step, and systems integrators would use the same version. While the upstream glibc has to go through a dance of pretending that someone cares about their independence.

Re: Linux kernel will support $ORIGIN, sort of

#68

Post by setheron »

jz391 wrote: post #4
nextaccountic wrote: post #3

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, w…

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

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

Re: Linux kernel will support $ORIGIN, sort of

#69

Post by aboardRat4 »

Siyo wrote: post #59
aboardRat4 wrote: post #53

Earlier quoted context omitted.

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

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.

If you don't own the software, the software can do many things to break nix' relocatable binaries too.

Re: Linux kernel will support $ORIGIN, sort of

#70

Post by erooke »

charcircuit wrote: post #63
roblabla wrote: post #22

Earlier quoted context omitted.

> 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." It's not really arrogance - it's just a different way to design a system. NixOS wants a few things: 1. An input-addressed dependency system 2. Easy and robust rollback/upgrades 3. Different versions of softw…

I suggest you take a look at Fedora Silverblue. It accomplishes all 3 of those goals.

I don't see how it achieves goal #1, what am I missing?
Post reply on HN