Nix + dotnet | 123 Members | |
| 23 Servers |
| Sender | Message | Time |
|---|---|---|
| 6 May 2025 | ||
| I'm just thinking about if we make a general hook for doing this. We might want to warn against using it on already patched things. Like you said it probably wouldn't break anything. Patched runtime would still explicitly load libs from /nix/store. | 13:57:17 | |
| yeah, looking at the actual effects of it, it'd only add a few unnecessary RPATH and needed entries | 13:57:53 | |
| but it wouldn't result in anything more in the nix store nor unnecessary packages being pulled in | 13:58:07 | |
| if it's a framework-dependent apphost, then the runtime in the nix store should already work, so perhaps we only need to identify self-contained apphosts? | 13:58:58 | |
Other than apphost and singlefilehost, is there anything else we need to worry about? Do they ship AOT things? | 13:59:13 | |
This would be | 14:00:07 | |
| AOT would indeed be an issue we need to worry about as well, I don't know how the AOT binaries are built, I'd need to check to see if they have ICU among the needed libraries | 14:00:06 | |
| I sort of doubt they would have that magic foobar hash in them. | 14:00:35 | |
let me check with patchcil | 14:01:01 | |
| it's the only AOT program we have in nixpkgs afaik | 14:01:09 | |
| But are they statically or dynamically linked against the ssl shim? | 14:01:09 | |
| it should be static, since it's a self-contained binary | 14:01:34 | |
| it should only need the external deps, no runtime nor anything else | 14:01:42 | |
| so AOT is always a single file? | 14:01:55 | |
| it has some auxliary files like the pdb and other native dlls (when nuget libraries use pinvoke), but I haven't seen AOT binaries with dlls | 14:02:40 | |
| * it has some auxliary files like the pdb and other native libraries (when nuget libraries use pinvoke), but I haven't seen AOT binaries with dlls | 14:02:46 | |
| annoyingly, it seems like it doesn't add OpenSSL, ICU nor Kerberos to the needed section:
| 14:03:46 | |
| * annoyingly, it seems like it doesn't add OpenSSL, ICU nor Kerberos to the needed section:
| 14:04:20 | |
In case it helps you can get an AOT build (and various other things) like dotnet-sdk.tests.console.cs.aot.built or similar | 14:07:26 | |
| oh nice | 14:07:41 | |
| there are tests for regular publish, single file, etc | 14:08:04 | |
| 7 May 2025 | ||
| 07:56:11 | ||
| 8 May 2025 | ||
Corngood: shouldn't this set DYLD_LIBRARY_PATH on macos? https://github.com/NixOS/nixpkgs/blob/b8d4a65cb17eb3ddec8f742f424a6d195500f281/pkgs/build-support/dotnet/build-dotnet-module/hooks/dotnet-fixup-hook.sh#L37 | 14:39:14 | |
| 9 May 2025 | ||
| Yeah, probably. Thanks for the PR. I think there are some subtle differences from glibc, but there are quite a few places in nixpkgs that use it as your suggesting. | 01:45:13 | |
| 14 May 2025 | ||
| 03:52:58 | ||
| 15 May 2025 | ||
| @corngood:corngood.com maybe we'll finally be able to source build feature bands in .NET 10? https://github.com/dotnet/announcements/issues/359 | 02:44:03 | |
| Interesting, but a little vague. For the upgrades this month, 8 is done, 9 hit https://github.com/dotnet/dotnet/pull/546, and I haven't started 10 yet. I guess when I get to 10 I'll see whats going on... | 10:57:57 | |
| 18 May 2025 | ||
Is there a suggested way to deal with an outdated global.json? Is it just to do something similar to substituteInPlace global.json --replace-fail 4.20.69 ${dotnetCorePackages.sdk_9_0.version}? | 22:41:17 | |
| ("Outdated" relative to the SDK that I'm using to build, anyway.) | 22:41:36 | |
Oh, maybe I could just change the allowPrerelease key to true? That may be the easiest solution here. | 22:47:52 | |