| 6 Dec 2024 |
 6pak | In reply to @lostmsu:matrix.org
Hey guys, I'm trying to see if there's a way to improve experience with C# code that has any kind of native dependencies (hi Avalonia).
Would love you to chime in before I jumped to experimentation: https://github.com/NixOS-NET/Nix.NET/issues/1 one idea I suggested before is making an IL patcher that patches all DllImport/NativeLibrary/dlopen uses and/or injects a DllImportResolver | 15:36:55 |
| 6pak | similar to patchelf | 15:36:59 |
| 7 Dec 2024 |
 GGG | the issue with that is NativeLibrary, it uses a dynamic string so we can't just detect what it's doing | 21:57:18 |
| GGG | sure, this isn't in C#, but still in .NET, look at this: https://github.com/dotnet/dotnet/blob/083e05a29d2b88f0d42bbca8f0b7ab33f4cfb7ab/src/runtime/src/native/libs/System.Security.Cryptography.Native/opensslshim.c#L67-L157 | 21:57:53 |
| GGG | However, even if it's just DllImport, I think it'd be beneficial to have it. And since we'll be scanning the source code anyways, we could change NativeLibrary calls with static strings and have an option to emit warnings for ones with dynamic ones (for debugging/packaging) | 22:08:06 |
| GGG | After I'm done with 361450 and 362278 I'll look into it. | 22:08:38 |
| GGG | Also, god, 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 paint | 22:19:37 |
| 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 paint | 22:27:11 |
| 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 |
