| 15 Dec 2025 |
 Ari Lotter | because dlopen doesn't check the runpath of libtorch_cuda.so does it | 20:06:36 |
| Ari Lotter | since dlopen ignores the caller's runpath | 20:06:48 |
| Ari Lotter | it only checks the runpath of the main executable.. | 20:06:55 |
| Ari Lotter | ok i have no idea what im doing <3 giving up | 20:11:43 |
| Ari Lotter | have managed to make it work by setting LD_LIBRARY_PATH but uhh seems pretty.. unusable | 20:13:36 |
| Ari Lotter | i think we'd have to patch the dlopen call | 20:13:40 |
| Ari Lotter | inside cudnn..? | 20:13:45 |
| Ari Lotter | https://github.com/NixOS/nixpkgs/issues/461334#issuecomment-3657416223 | 20:19:51 |
| Ari Lotter | i think it's pretty hopeless. lol | 20:19:58 |
 connor (burnt/out) (UTC-8) | I’ve not; I suspect zero speedup since evaluating a single config doesn’t have opportunities for parallelism and all the locking is done through kernel structures so it should be super low overhead
(Also Nixpkgs basically forbids eval time fetchers so I don’t think a config using just Nixpkgs would show a speedup) | 20:39:18 |
| connor (burnt/out) (UTC-8) | That was evaluating all of the closures attribute in nixos/release.nix with nix eval --json | 20:40:10 |
| connor (burnt/out) (UTC-8) | There is some, but it blocks forever, doesn’t do cleanup, and lacks a few other features needed for different types of builtin fetchers and substitutions | 20:41:22 |
| connor (burnt/out) (UTC-8) | Robbie Buxton have you run into this (or seen anyone run into it)? You’re one of the like three people I know who use PyTorch from Nixpkgs other than myself | 20:42:49 |
 Robbie Buxton | In reply to @connorbaker:matrix.org
Robbie Buxton have you run into this (or seen anyone run into it)? You’re one of the like three people I know who use PyTorch from Nixpkgs other than myself I haven’t run into that but I have run into libcuda failing on trying to dlopen things it claims to not depend on | 21:07:52 |
| Robbie Buxton | Regarding that issue iirc RPATHS are recursive but RUNPATHS aren’t and if a RUNPATH exists the RPATH won’t be used (its replacing RPATHs) | 21:12:39 |
| Robbie Buxton | I think @[Ari Lotter] is right and we should add it as an (undocumented) dep or cudnn | 21:15:47 |
| Robbie Buxton | * I think @[Ari Lotter] is right and we should add it as an (undocumented) dep of cudnn | 21:15:56 |
 apyh | adding it as a cudnn dep doesn't work still though from my testing | 21:16:10 |
| Robbie Buxton | How are you adding it? | 21:16:20 |
| apyh | i tried it as a propagatedBuildInput | 21:16:30 |
| apyh | the only thing i managed was to pass it in ld library path manually :/ | 21:16:43 |
| Robbie Buxton | Oh you’ll need to patchelf it | 21:16:44 |
| apyh | err.. but it uses dlopen, right? | 21:17:13 |
| Robbie Buxton | Sure but then it’ll know where it is no? | 21:17:32 |
| apyh | my understanding is that bare soname dlopen doesn't care about that | 21:18:01 |
| apyh | like we'd have to patch the *python* binary | 21:18:13 |
| apyh | (very possible. I'm completely wrong here though, this is all new to me) | 21:18:23 |
| Robbie Buxton | A bare no name dlopen will check the runpaths for where it’s being called form | 21:18:26 |
| apyh | right, but that's the top level executable, python, not the libraries in the chain, no? | 21:18:58 |
| Robbie Buxton | Nah each library checks its own runpath | 21:19:15 |
