4 ms·

As I understand it, Nixos runs their own patched versions of ld and the dynamic loading system calls in libc. The normal lib.so search mechanism is replaced wh

As I understand it, Nixos runs their own patched versions of ld and the dynamic loading system calls in libc. The normal lib.so search mechanism is replaced wholesale with "thou shalt link against this dll and no other" on a per-execuatble basis. Multiple versions of .so's don't cause problems, because no executable is depending on a search mechanism it doesn't control.

ambrop7 10y ago
I think that they don't do too drastic changes. There are certainly checks in the compilation process to not accidentally link to /usr/lib/ libraries, but I think the main problem of finding libraries works with a simple compiler wrapper adding needed -Lflags (for finding libs at compile time) and RPATH entries to binaries (for finding libs at run time). There of course may be "hacks" made to gcc/libc but I don't see a reason they would be essential for functioning. One notable thing Nix does is hardcode a path to a specific dynamic linker (e.g. /nix/store/HASH-glibc-2.23/lib/ld-linux-x86-64.so.2). All other dynamic libraries should be referenced through soname+RPATH.
- dbcurtis 10y ago
  I agree that the changes are likely not extremely invasive, and I would hesitate to call them "hacks". OTOH, it does make Nixos fundamentally different from other (u)nix systems. They are basically saying it's time to hard-fork the (u)nix philosophy about how dynamic linking is done. They might be right. It's a very interesting approach, and I want to understand it in detail. I haven't had the time to bring up a Nixos system yet, though.
vertex-four 10y ago
Actually, I think they use the standard ld.so... it's just that for every executable, the RPATH in the header of the executable is set to a list of directories where the libraries it was built against can be found. ld.so uses the RPATH to find libraries by default.
- ambrop7 10y ago
  No they definitely use a nonstandard ld.so path. What I showed above is actual output of ldd except there's an actual HASH. If you think about it makes sense, glibc is still "just" a dependency so it needs to be references from dependant packages by a concrete /nix/store path. You wouldn't want to have a single global libc.so, because you want to be able to upgrade one application using different/newer OS components including libc without possibly breaking existing applications. The ld.so path is basically the first thing you need to fix when packaging prebuilt software (using patchelf); the second thing are RPATH for other library dependencies. EDIT: Yes the ld.so probably isn't patched, I failed to completely read your comment. If you want to know really you'd have to look into nixpkgs of course.
  - vertex-four 10y ago
    They use a nonstandard ld.so path so that if you build a given binary with a given version of gcc, it uses that gcc's ld.so - but the ld.so isn't patched.

ambrop7 10y ago

I think that they don't do too drastic changes. There are certainly checks in the compilation process to not accidentally link to /usr/lib/ libraries, but I think the main problem of finding libraries works with a simple compiler wrapper adding needed -Lflags (for finding libs at compile time) and RPATH entries to binaries (for finding libs at run time). There of course may be "hacks" made to gcc/libc but I don't see a reason they would be essential for functioning. One notable thing Nix does is hardcode a path to a specific dynamic linker (e.g. /nix/store/HASH-glibc-2.23/lib/ld-linux-x86-64.so.2). All other dynamic libraries should be referenced through soname+RPATH.

dbcurtis 10y ago
I agree that the changes are likely not extremely invasive, and I would hesitate to call them "hacks". OTOH, it does make Nixos fundamentally different from other (u)nix systems. They are basically saying it's time to hard-fork the (u)nix philosophy about how dynamic linking is done. They might be right. It's a very interesting approach, and I want to understand it in detail. I haven't had the time to bring up a Nixos system yet, though.

vertex-four 10y ago

Actually, I think they use the standard ld.so... it's just that for every executable, the RPATH in the header of the executable is set to a list of directories where the libraries it was built against can be found. ld.so uses the RPATH to find libraries by default.

ambrop7 10y ago
No they definitely use a nonstandard ld.so path. What I showed above is actual output of ldd except there's an actual HASH. If you think about it makes sense, glibc is still "just" a dependency so it needs to be references from dependant packages by a concrete /nix/store path. You wouldn't want to have a single global libc.so, because you want to be able to upgrade one application using different/newer OS components including libc without possibly breaking existing applications. The ld.so path is basically the first thing you need to fix when packaging prebuilt software (using patchelf); the second thing are RPATH for other library dependencies. EDIT: Yes the ld.so probably isn't patched, I failed to completely read your comment. If you want to know really you'd have to look into nixpkgs of course.
- vertex-four 10y ago
  They use a nonstandard ld.so path so that if you build a given binary with a given version of gcc, it uses that gcc's ld.so - but the ld.so isn't patched.