Nix + dotnet | 121 Members | |
| 24 Servers |
| Sender | Message | Time |
|---|---|---|
| 6 May 2025 | ||
| 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 | |
| what is your actual case? | 22:48:21 | |
| is the global.json pinning a exactly specific version? | 22:48:32 | |