| 13 Sep 2025 |
 emily | (but actually it should be lib.meta.availableOn stdenv.hostPlatform wayland) | 00:11:12 |
| emily | I'm so mad about this | 00:11:33 |
 Randy Eckenrode | I think technically wayland should build on Darwin even though it’s useless. | 00:12:06 |
| emily | well, more to the point it's something you actively want on e.g. FreeBSD | 00:12:30 |
| Randy Eckenrode | Just a bunch of protocol description stuff. Nothing useful IIRC. | 00:12:34 |
 kfiz | indeed:
nix-repl> pkgs.lib.meta.availableOn pkgs.stdenv.hostPlatform pkgs.wayland
true | 00:27:59 |
| emily | well, it should be badPlatforms if it doesn't actually build… | 00:29:20 |
| emily | but probably not related to whatever the problem is here | 00:30:03 |
| Randy Eckenrode | It probably built in the past, but no one checked Darwin in an update. | 00:35:11 |
| emily | szlend: I fixed that mold crash btw | 02:51:46 |
 Ihar Hrachyshka | Wayland doesn't build for Darwin now but there are upstream patches in progress to make it work | 05:10:24 |
| Ihar Hrachyshka | https://github.com/NixOS/nixpkgs/pull/435145 | 05:11:27 |
 szlend | That’s awesome! I’m curious what caused it | 06:35:59 |
| emily | it's horribly cursed https://github.com/NixOS/nixpkgs/pull/442554 | 06:37:03 |
| emily | they have their library dlopen another one that dlopens itself to keep it alive | 06:37:24 |
| emily | otherwise stuff that it calls destructors on in a static destructor vanishes | 06:37:45 |
| emily | but it uses a relative path name without making it absolute for just that one call | 06:38:00 |
| emily | so it fails to keep it alive on macOS where we use absolute paths to libraries rather than rpaths | 06:38:18 |
| emily | and silently ignores that error until any binary that links it segfaults on exit | 06:38:34 |
| szlend | Yikes, great job figuring all that out. I tried to attach a debugger and stepped through the code and couldn’t make any sense of it. I would have never considered that as a possibility haha | 06:44:24 |
| emily | yeah I saw in the PR where it broke Nix that it was happening even for a trivial libblake3 test program that linked it but didn't use it | 06:45:41 |
| emily | looked in LLDB, saw that it was static dtor stuff, glanced at the code and saw that it was calling destructors on invalid pointers, tried to step through the startup code in LLDB to no avail, set the environment variable to trace dyld logs to get some idea of how that stuff was fitting together, saw dlopen calls that were mixed relative and absolute, got a hunch, added an rpath to the blake3 example and tada it worked | 06:47:27 |
| emily | grepped the code for dlopen calls, saw that it constructed absolute paths for its main call but then there was this one direct call to keep itself alive that wasn't doing that | 06:48:01 |
| emily | and here we are | 06:48:05 |
| emily | it has been 0 days since it was rpath | 06:48:35 |
| emily | (I only started looking at this because TBB 2021 is broken by the LLVM 21 jump so I'm like four yak shaves deep...) | 06:49:18 |
| emily | that mystery had been bugging me a little ever since it came up in here though so I'm glad it's resolved | 06:49:49 |
| emily | now we just need someone to figure out the bizarre nondeterministic Git codesigning bug. @zhaofeng:zhaofeng.li we need you... | 06:50:17 |
 Zhaofeng Li | Oh right, need to come back to this issue. Got really sidetracked and changed to git from gitFull myself 🫠 | 11:38:19 |
|  oak 🏳️🌈♥️ changed their profile picture. | 09:44:25 |
