!VRULIdgoKmKPzJZzjj:nixos.org

Nix Hackers

932 Members
For people hacking on the Nix package manager itself195 Servers

Load older messages


SenderMessageTime
7 Mar 2026
@eveeifyeve:matrix.orgeveeifyeveDid I hear someone say freebsd sandbox building?16:22:04
8 Mar 2026
@ss:someonex.netSomeoneSerge (matrix works sometimes) changed their display name from SomeoneSerge (back on matrix) to SomeoneSerge (matrix works sometimes).23:28:36
9 Mar 2026
@gerasti:matrix.orgsantg3ar changed their display name from gerasti to santg3ar.22:05:42
10 Mar 2026
@fzakaria:one.ems.hostfzakaria

Sharing this from Spack (spack.io) how they handle OpenGL or runtime type library dependencies:

If a binary is built in a CI/CD pipeline at /opt/spack/build/... and you download it to /home/user/super_long_project_name/spack/..., Spack needs to rewrite the RPATH in the ELF binary.

The Problem: You can safely shrink a string in a compiled binary, but if you try to replace a string with a longer one, you will overwrite adjacent memory and corrupt the executable.

The Solution: Spack uses a configuration called padded_length (often set to 128 characters or more). During the initial build, Spack intentionally pads the installation path with extra characters. This forces the compiler to generate massive, padded RPATH strings in the binary.

When you download the binary cache, Spack's relocation logic strips out the padding and inserts your local, shorter path. Because the original string was artificially inflated, Spack always has enough room to rewrite the path without breaking the binary.
00:18:29
@fzakaria:one.ems.hostfzakariatl;dr; Spack puts a 128 length padded entry in RPATH for the library (i.e. OpenGL). At realisation, the ELF binary is modified to point to the live running library.00:19:15
@dramforever:matrix.orgdramforevernot reaaaly an option for nix02:24:10
@dramforever:matrix.orgdramforeverand for regular rpath rewriting while building, we've been patchelf-ing everything which handles making a new PT_DYNAMIC02:25:21
@dramforever:matrix.orgdramforeverso that's also not a problem02:25:25
@dramforever:matrix.orgdramforever* so that's also "not" a problem02:25:35
@eveeifyeve:matrix.orgeveeifyeveSpeaking about patchelf, there has been discussion about using fixpath instead.07:25:44
@eveeifyeve:matrix.orgeveeifyeve* Speaking about patchelf, there has been discussion about using fixpath or some alternative instead, which I don't remember.07:26:18
@eveeifyeve:matrix.orgeveeifyeve* Speaking about patchelf, there has been discussion about using fixpath or some alternative instead, which I don't remember. But the reason is for windows and unix are very different binary formats eg. windows being Pe (portable exe), linux being elf, macos being mach-o.07:29:18
@dramforever:matrix.orgdramforeverif you mean https://github.com/nixcloud/fixPath i think that's PE-only, so "additionally", not "instead"07:33:45
@wamserma:nixos.dev@wamserma:nixos.dev left the room.08:45:47
@5ulu5:matrix.org@5ulu5:matrix.org left the room.12:07:25
@mtheil:scs.ems.host@mtheil:scs.ems.host left the room.14:24:52
@mkalv:matrix.orgMax Kalvesmaki joined the room.14:38:36
11 Mar 2026
@matthewahiles:matrix.orgMatthew Hiles joined the room.03:48:02
@pveierland:matrix.orgpveierland Did something change in the behavior of indirect flakeref resolution? nix registry resolve nixpkgs/a3a3dda3bacf61e8a39258a0ed9c924eeca8e293 works but nix registry resolve nixpkgs/nixos-unstable/a3a3dda3bacf61e8a39258a0ed9c924eeca8e293 fails with error: cannot apply both a commit hash (a3a3dda3bacf61e8a39258a0ed9c924eeca8e293) and a branch/tag name ('nixos-unstable') to input 'github:NixOS/nixpkgs/nixpkgs-unstable' 09:30:45
@ctheune:matrix.flyingcircus.ioTheuni changed their display name from Theuni to Christian Theune.14:11:47
@tyler_pb:matrix.orgTyler_PB joined the room.19:49:40
@lisanna-dettwyler:matrix.orgLisannaI'm trying to think of a way to asynchronously drain a file descriptor into a sink, is it safe to write to a sink from a different thread, assuming that's the only writer?21:51:32
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)I think source.drainInto(sink) is good for this, there are different overloads. A buffered sink only cares about having one writer22:10:32
@xokdvium:matrix.orgSergei Zimmerman (xokdvium)(Same for the source too)22:10:55
@lisanna-dettwyler:matrix.orgLisannaalright, I'll give it a shot <322:13:57
@lisanna-dettwyler:matrix.orgLisanna man I don't even have nix registry resolve, is it new? 22:17:41
@lisanna-dettwyler:matrix.orgLisanna

Gonna try something like this:

AsyncPostBuildHookInfo info;
info.act = std::make_unique<Activity>(
    *logger,
    lvlTalkative,
    actPostBuildHook,
    fmt("running async-post-build-hook '%s'", worker.settings.asyncPostBuildHook),
    Logger::Fields{worker.store.printStorePath(drvPath)});
info.sink = std::make_unique<LogSink>(*info.act);
info.out = std::make_unique<Pipe>();
info.out->create();
info.out->writeSide.close();
info.handleOutput = std::thread([&](Descriptor readSide, Sink & sink) {
    drainFD(readSide, sink);
}, info.out->readSide.get(), *info.sink);

// PushActivity pact(info.act->id);

auto pid = runAsyncPostBuildHook(worker.settings, worker.store, *info.out, drvPath, outputPaths);

worker.asyncPostBuildHooks[pid] = std::move(info);
23:03:32
@lisanna-dettwyler:matrix.orgLisanna *

Gonna try something like this:

AsyncPostBuildHookInfo info;
info.act = std::make_unique<Activity>(
    *logger,
    lvlTalkative,
    actPostBuildHook,
    fmt("running async-post-build-hook '%s'", worker.settings.asyncPostBuildHook),
    Logger::Fields{worker.store.printStorePath(drvPath)});
info.sink = std::make_unique<LogSink>(*info.act);
info.out = std::make_unique<Pipe>();
info.out->create();
info.out->writeSide.close();
info.handleOutput = std::thread([](Descriptor readSide, Sink & sink) {
    drainFD(readSide, sink);
}, info.out->readSide.get(), *info.sink);

// PushActivity pact(info.act->id);

auto pid = runAsyncPostBuildHook(worker.settings, worker.store, *info.out, drvPath, outputPaths);

worker.asyncPostBuildHooks[pid] = std::move(info);
23:04:31
12 Mar 2026
@pveierland:matrix.orgpveierlandYeah, November 2025: https://github.com/NixOS/nix/commit/063cdb5508bb4a6917eff25e8f8da55ecfedae2e00:28:38
@lisanna-dettwyler:matrix.orgLisannayep, it works!01:16:43

Show newer messages


Back to Room ListRoom Version: 6