| 7 Dec 2024 |
 GGG | * Also, I can't wait for CA derivations, having to rebuild thousands of packages because of my changes that shouldn't affect anything in 361450 is becoming a major pain | 22:27:21 |
 6pak | In reply to @gggkiller:matrix.org
the issue with that is NativeLibrary, it uses a dynamic string so we can't just detect what it's doing that's where "injects a DllImportResolver" would come in | 23:13:11 |
| 6pak | and if it's a simple NativeLibrary.Load("static string") we can detect that easily | 23:14:24 |
| GGG | registering a resolver would be a major pain though, since it has to be done per assembly | 23:16:56 |
| GGG | we could do it, but it'd be very annoying | 23:17:01 |
| GGG | I think for dynamic libraries it's just easier to edit the LD_PRELOAD_PATH and/or RPATH of the apphost | 23:19:23 |
| GGG | though I understand that'd be annoying for libraries | 23:20:21 |
| 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 |
