 | Nix + dotnet | 126 Members |
| 24 Servers |
| Nix + dotnet | 126 Members |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 7 Dec 2024 | ||
 6pak | because zlib is statically linked now | 23:56:30 |
 GGG | openssl | 23:56:34 |
| GGG | * openssl too | 23:56:39 |
| 6pak | oh right | 23:56:40 |
| 8 Dec 2024 | ||
| GGG | ideally the repo should be under the NixOS org, but I guess initially we'll have to leave it in one of our accounts before we get it fully working and widespread use | 00:09:20 |
| GGG | it'd also be nice to have an equivalent of autoPatchelfHook | 00:09:28 |
| GGG | Corngood: any tips to speed up the SDK source build? or no option other than just wait? | 00:37:22 |
| GGG | it is pretty slow on my machine, takes a bit over an hour | 00:37:42 |
 Corngood | Unfortunately I don't think so. It's brutal, and it seems to go pretty wide for most of the build. I think it might be overkill to built your patchelf change with the source builds of both sdk 8 and 9. | 00:40:13 |
| Corngood | * Unfortunately I don't think so. It's brutal, and it seems to go pretty wide for most of the build. I think it might be overkill to build your patchelf change with the source builds of both sdk 8 and 9. | 00:40:30 |
| GGG | I mean, the issue is that quite a few packages use the source-built version of the SDK, and the source builds themselves also use that patchelf | 00:40:48 |
| GGG | * I mean, the issue is that quite a few packages use the source-built version of the SDK, and the source builds themselves also use that patchelf change | 00:40:50 |
| GGG | so I need to be sure nothing broke | 00:40:57 |
| GGG | if we had content-addressed derivations by default at least it'd detect nothing actually changed and skip the builds for the rest | 00:42:55 |
| GGG | but that's still a way's away unfortunately | 00:43:01 |
| GGG | huh, the way alcom works is really weird | 04:00:34 |
| GGG | it uses dotnetBuildModule but then throws away everything from it except nugetDeps | 04:00:48 |
| GGG | how does that even work | 04:00:51 |
| 9 Dec 2024 | ||
 lostmsu | Wait, why would you write a tool if you could just modify the .NET itself | 03:01:14 |
| 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 |