| 9 Jan 2025 |
 GGG | * 6pak: got back to looking at patchcil and I found where it lists the paths for native dependencies | 13:01:52 |
| GGG | but it seems like after the build, it just copies them to the root | 13:02:42 |
| GGG | 
Download image.png | 13:02:44 |
| GGG | so I don't know if we really need to read .deps.json or not, but I guess I'll implement it regardless | 13:03:15 |
| GGG | seems like no packages have the runtime/{rid} in their output either: | 13:12:36 |
| GGG | 
Download image.png | 13:12:39 |
 6pak | I forgot it will get flatten out when building for a specific RID, yeah | 15:49:48 |
| 6pak | what does the deps.json point to in that case? | 15:49:57 |
| 6pak | still a runtimes/whatever directory or to root? | 15:50:10 |
| 6pak | (it will have root in search path regardless so it could be either I guess) | 15:50:34 |
| GGG | In reply to @6pak:matrix.org
still a runtimes/whatever directory or to root? I mean, there's the runtime dir in .deps.json so I'll add that to the search path instead of doing the manual search in there as it could be literally anywhere | 15:52:14 |
| GGG | But idk if it adds to the search path only for that assembly or all of them | 15:52:32 |
| 6pak | for the assembly load context afaik | 15:52:50 |
| GGG | I see | 15:53:02 |
| 6pak | so unless the program creates a new one, it will be for all | 15:53:03 |
| 6pak | * so unless the program creates a new (isolated) one, it will be for all | 15:53:45 |
| GGG | That's rather annoying, because then native library resolution is dependent on control flow | 15:53:46 |
| GGG | So it could be entirely indeterministic | 15:53:59 |
| GGG | I think maybe we'll need to add the custom resolution logic long term | 15:57:46 |
| GGG | Similar to the RPATH thing | 15:57:51 |
| GGG | Or maybe just outright scan all needed libraries, read the RPATH of the app host and error if it's not there, which would be the faster/easier option | 15:58:31 |
| 6pak | whats even the point of app hosts on nixos | 15:59:29 |
| GGG | I meant the apphost binary, the executable it generates on the output | 16:00:25 |
| GGG | But yeah, there's no point | 16:00:36 |
| 6pak | yes I know, but do we need those for programs in nixpkgs | 16:00:41 |
| GGG | We could likely replace it with a `makeBinaryWrapper` | 16:00:54 |
| 6pak | it's just unnecessary work on startup to find the dotnet runtime, and makes it less deterministic | 16:00:57 |
| GGG | Well, for some programs it's useful since they want to use the installed SDK | 16:01:22 |
| GGG | Like roslyn-ls | 16:01:27 |
| GGG | But other than those, it's not really necessary | 16:01:36 |
