Nix + dotnet | 127 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 13 Dec 2024 | ||
| ok, managed to write the code for an auto patchcil command, haven't tested yet, will leave that for tomorrow https://github.com/GGG-KILLER/patchcil/blob/main/src/Commands/AutoCommand.cs | 06:33:41 | |
| seems to output the expected errors, although I'll have to see about finding the libraries:
| 06:36:58 | |
| looks pretty good | 15:52:03 | |
| rid-graph-gen is interesting, but fyi there is a C# reader for the graph here https://github.com/dotnet/dotnet/blob/v9.0.101/src/nuget-client/src/NuGet.Core/NuGet.Packaging/RuntimeModel/JsonRuntimeFormat.cs | 15:52:34 | |
| which the sdk uses | 15:52:38 | |
so you could have just done JsonRuntimeFormat.ReadRuntimeGraph(<$(RuntimeIdentifierGraphPath) from msbuild>).ExpandRuntime("linux-x64") | 15:53:14 | |
and looking more into the runtimes/{rid}/native/{libname}.so pattern seems like it's only a build-time nuget thing | 16:24:33 | |
| the runtime only looks at the .deps.json file to discover the library paths, which dotnet sdk populates from nuget info | 16:25:38 | |
* and looking more into the runtimes/{rid}/native/{libname}.so pattern, seems like it's only a build-time nuget thing | 16:26:54 | |
| and it does pick just the best matching rid, but only inside one dependency | 16:42:40 | |
| and even though it has the full library path, it registers the directory as a search path | 16:43:59 | |
so if lib A has runtimes/linux-x64/native/liba.so and lib B has runtimes/linux-musl-x64/native/libb.so, both runtimes/linux-x64/native and runtimes/linux-musl-x64/native will be registered as native search paths | 16:47:02 | |
In reply to @6pak:matrix.orgThat's an interesting idea, however I wanted to have everything as optimized as possible, although I know most of the overhead will be in AsmResolver, I wanted to have little to no overhead on anything else so this doesn't slow down any builds My long term objective with this is to use NativeAOT to have a really good cold start performance | 22:04:01 | |
| Don't know if I'm overthinking this though | 22:04:14 | |
In reply to @6pak:matrix.orgYes, however my plan is to use autoPatchcil on the nuget restore step so nuget libraries with native tools and stuff work just fine Long term I also want to find and transform any self-contained deployments into framework dependent ones so that they use the nixpkgs SDK/runtime instead of their own bundled one, that way we can avoid issues with ICU, openssl and libz | 22:06:56 | |
| * Yes, however my plan is to use autoPatchcil on the nuget restore step so nuget libraries with native tools and stuff work just fine as they'll probably run on the build step (like the grpc package and entity framework) Long term I also want to find and transform any self-contained deployments into framework dependent ones so that they use the nixpkgs SDK/runtime instead of their own bundled one, that way we can avoid issues with ICU, openssl and libz | 22:07:42 | |
In reply to @6pak:matrix.orgThat's good to know, I'll look into it and try to add that logic into the command | 22:08:50 | |
| Also, while running it in a dry run against avalonia, I ran into something rather unpleasant | 22:11:45 | |
| There's `.dll` and `.dylib` imports in it as well, so it won't be as plug'n'play as `autoPatchelfHook`, I had to add quite a few thing to the ignores list like `*.dll`, `kernel32`, `user32` and more | 22:13:17 | |
| It might be worth adding an option to exclude certain files on top of ignoring certain imports | 22:13:51 | |
| 14 Dec 2024 | ||
| corehost parses the json every launch so it would probably be fine? | 01:34:55 | |
I meant that the runtime doesn't look at the runtimes/{rid}/native path, it's the nuget client that checks it in the packages and converts it into metadata that the .net sdk then puts into the final .deps.json | 01:37:31 | |
| but build time nuget packages requiring native libs themselves is a valid point | 01:38:40 | |
| wouldn't it make more sense to run (auto)patchcil as part of nuget overrides though? | 01:38:57 | |
| yeahh thats fair | 01:41:31 | |
it would be nice if people annotated those with SupportedOSPlatformAttribute, but they probably don't | 01:41:54 | |
In reply to @6pak:matrix.orgI mean, it probably wouldn't be much overhead, I'm probably just overthinking it, but since it's already done, I wouldn't just throw it away myself | 01:43:21 | |
In reply to @6pak:matrix.orgOh, I see, that's indeed a big issue, I'll have to remove those lines from the logic since it's nuget only | 01:44:19 | |
| it just so happens that it's the same path in the output usually | 01:44:49 | |
| but in theory the .deps.json could specify any path | 01:44:58 | |