| 7 Dec 2024 |
 GGG | though through native code afaika | 23:55:53 |
| GGG | * though through native code afaik | 23:56:00 |
| GGG | I'd have to look to see if anything uses NativeLibrary.Load | 23:56:15 |
 6pak | and only icu in .NET 9+ | 23:56:21 |
| 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.org
Wait, why would you write a tool if you could just modify the .NET itself the same reason you patch the elfs not the system linker | 20:45:03 |
| lostmsu | In reply to @6pak:matrix.org
the same reason you patch the elfs not the system linker but dotnet is not a linker - it is a runtime platform
you 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 |
