| 7 Dec 2024 |
 6pak | In reply to @gggkiller:matrix.org
registering a resolver would be a major pain though, since it has to be done per assembly but it also means you can safely inject a native dep to a nuget dependency knowing it wont break anything else | 23:20:48 |
 GGG | true, but for multi-assembly packages it'd become annoying I assume | 23:22:16 |
| 6pak | I doubt multi assembly packages will dynamically load the same native lib in different managed assemblies | 23:23:01 |
| GGG | we also won't be able to have something akin to --shrink-rpath from patchelf since they can dynamically load libraries and there's no equivalent of --add-needed for dotnet | 23:23:08 |
| 6pak | I'd imagine in that case you would have one assembly responsible for the native thing | 23:23:10 |
| GGG | I'd just distribute the native libs per scope | 23:23:26 |
| GGG | IO stuff in one assembly, net in another ,etc | 23:23:32 |
| GGG | though if IO and net share the same library then owell | 23:23:41 |
| 6pak | In reply to @gggkiller:matrix.org
we also won't be able to have something akin to --shrink-rpath from patchelf since they can dynamically load libraries and there's no equivalent of --add-needed for dotnet would --shrink-rpath be useful in anyway here? | 23:25:06 |
| GGG | for the dynamic DllImport resolver maybe | 23:25:32 |
| GGG | remove things that aren't being used | 23:25:56 |
| GGG | although I guess the ideal would be to just not add them in the first place | 23:26:08 |
| 6pak | ^ | 23:26:14 |
| GGG | I'm thinking too much of just implementing patchelf for CIL and not thinking too much about the differences 😅 | 23:26:24 |
| 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 |
