 | Nix + dotnet | 127 Members |
| 24 Servers |
| Nix + dotnet | 127 Members |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 9 Dec 2024 | ||
 lostmsu | https://github.com/dotnet/runtime/blob/f8f713e3c6f10570cd8911f10bfb4e43bba4b072/src/libraries/System.Private.CoreLib/src/System/Runtime/InteropServices/NativeLibrary.cs#L29 | 03:04:07 |
 Corngood | I think just because we still use the binary runtime. Hopefully in the future we can just patch it | 03:06:39 |
 6pak | In reply to @lostmsu:matrix.orgthe same reason you patch the elfs not the system linker | 20:45:03 |
| lostmsu | In reply to @6pak:matrix.orgbut dotnet is not a linker - it is a runtime platformyou don't patch .NET framework - targeted executables to run on Mono on Linux, you change Mono to use different platform calls when they run on Linux | 23:51:53 |
| 10 Dec 2024 | ||
| 6pak | I mean in nixpkgs you do patch the native executables/libraries to use full nix store paths for dependencies using patchelf | 15:40:14 |
| 6pak | so you can do pure side by side installs etc | 15:40:21 |
| 6pak | the other approach is making wrapper scripts that add the dependencies to LD_LIBRARY_PATH everywhere (which is what dotnet in nixpkgs does today) | 15:41:04 |
| 6pak | but it's annoying and only works for executables | 15:41:37 |
| 6pak | has anyone ever looked into making fetch-deps use GenerateRestoreGraphFile instead doing a full restore? | 16:32:32 |
| 6pak | * has anyone ever looked into making fetch-deps use GenerateRestoreGraphFile instead of doing a full restore? | 16:32:39 |
| Corngood | In reply to @6pak:matrix.org I haven't. There are a lot of nuances to finding the actual dependencies: dotnet tools, paket, etc. It might still be useful if it can be used for a subset of packages, either opt-in or out. | 16:50:30 |
| 11 Dec 2024 | ||
| lostmsu | OK, leaving aside the runtime behavior, can anyone think of a way to modify my C# project with native dependency to make it fail building under Nix if that dependency is not declared in Nix? | 23:15:44 |
| 12 Dec 2024 | ||
 GGG | Simply not possible. Nix currently has no resources for determining which native libraries your project uses so it cannot make the build fail. Even if your project is being built from source using buildDotnetModule, .NET has no builtin facilities to block a build if said native libraries aren't found either. | 00:00:52 |
| GGG | And we add the required libraries in LD_PRELOAD_PATH instead of at build time, so even if there was a tool to block the build if the native library isn't found, it'd have to be very nix specific as we'd have to have an env-var or MSBuild property to indicate where it should search for said libraries on. | 00:02:14 |
| GGG | * And we add the required libraries in LD_PRELOAD_PATH in makeWrapper (after the project has been built) instead of at build time, so even if there was a tool to block the build if the native library isn't found, it'd have to be very nix specific as we'd have to have an env-var or MSBuild property to indicate where it should search for said libraries on. | 00:02:32 |
 Emma [it/its] | cant you fail the build with an msbuild target? | 00:03:29 |
| GGG | * And we add the required libraries in LD_LIBRARY_PATH in makeWrapper (after the project has been built) instead of at build time, so even if there was a tool to block the build if the native library isn't found, it'd have to be very nix specific as we'd have to have an env-var or MSBuild property to indicate where it should search for said libraries on. | 00:04:21 |
| GGG | no, because we'd need to have something to:
| 00:05:50 |
| GGG | it'd be as much work as making something like a tool to patch those after the fact | 00:06:08 |
| GGG | so it's just easier to make a tool to patch it since it'll work with both source builds and prebuilt binaries | 00:06:28 |
| GGG | * not easily, because we'd need to have something to:
| 00:06:37 |
| 6pak | actually this made me think, GGG how would patchcil handle nativeaot builds? | 00:08:31 |
| GGG | it can't, out of scope | 00:08:41 |
| GGG | we'd just have to use LD_LIBRARY_PATH instead | 00:08:51 |
| 6pak | In reply to @gggkiller:matrix.orgpatchcil would solve 1. here, but for 2. and 3. would be in the nix script | 00:08:55 |
| GGG | * we'd just have to use LD_LIBRARY_PATH instead like we do currently | 00:08:56 |
| 6pak | In reply to @gggkiller:matrix.org* for what I was thinking, patchcil would solve 1. here, but for 2. and 3. would be in the nix script | 00:09:09 |
| GGG | it'd actually solve the whole process when running in autoPatchcilHook mode | 00:09:15 |
| GGG | which is the more "useful" mode I think | 00:09:31 |
| 6pak | In reply to @gggkiller:matrix.orgit can for source builds | 00:09:51 |