| 7 Dec 2024 |
 6pak | I thought the use case for --shrink-rpath is only when you get precompiled binaries which already have some rpath | 23:26:40 |
| 6pak | when you build yourself you can just not add stuff you don't need | 23:26:51 |
 GGG | pretty much, or when you just call --add-rpath with the same library set for all ELFs in $out and then want to clean everything up | 23:27:18 |
| GGG | say you don't want to have to figure out which libraries each binary needs, so you just do mass patchelf --set-rpath "$RPATH" "$file"; patchelf --shrink-rpath "$file"; | 23:27:52 |
| GGG | which could also happen in our case I guess | 23:28:38 |
| 6pak | we could have our own "fake" --add-needed though | 23:28:54 |
| GGG | how would we manage that though | 23:29:02 |
| GGG | resource files? | 23:29:04 |
| GGG | * resource files/strings? | 23:29:09 |
| 6pak | we have to inject DllImportResolver in some way anyway | 23:29:18 |
| 6pak | so I thought of making a <NixInitClassWhatever> with a ModuleInitializer method in it | 23:29:35 |
| 6pak | might aswell add a static string[] Needed property to it | 23:29:45 |
| GGG | yeah, we can do that, but I'd like a way to manage stuff without needing to decompile code | 23:29:52 |
| GGG | I guess having a static readonly array could work | 23:30:02 |
| GGG | but that wouldn't be very efficient since we'd need to linearly iterate through it | 23:30:17 |
| 6pak | eh | 23:30:45 |
| 6pak | you need to iterate over every method to find DllImport attributes anyway | 23:30:53 |
| GGG | though that should only matter for big stuff like game engines | 23:30:56 |
| GGG | yeah, but that's compile time, not runtime | 23:31:05 |
| GGG | I'm worried about possible performance impacts to applications running in nixos | 23:31:17 |
| GGG | and those would be very hard to debug since we'd be "invisibly" (to the end user) adding stuff to the code | 23:31:39 |
| 6pak | I mean isn't that how dynamic linker works in native land | 23:31:46 |
| GGG | * and those would be very hard to debug since we'd be "invisibly" (to the end user and original package maintainers) adding stuff to the code | 23:31:49 |
| GGG | well, it loads stuff up on boot | 23:32:00 |
| GGG | nothing prevents someone from calling NativeLibrary.Load multiple times | 23:32:12 |
| GGG | as dumb as that would be | 23:32:15 |
| 6pak | it gets cached afaik | 23:32:21 |
| GGG | though I guess then the blame is on the dev | 23:32:23 |
| 6pak | but it might get cached by the file path returned from the resolver | 23:32:43 |
| 6pak | * but it might get cached on the file path returned from the resolver | 23:32:47 |
