| 24 Sep 2025 |
Whovian9369 | $ readelf -d _build
Dynamic section at offset 0x106c8 contains 33 entries:
Tag Type Name/Value
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/netcoredeps]
0x0000000000000001 (NEEDED) Shared library: [libpthread.so.0]
0x0000000000000001 (NEEDED) Shared library: [libdl.so.2]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000001e (FLAGS) BIND_NOW
0x000000006ffffffb (FLAGS_1) NOW PIE
0x0000000000000015 (DEBUG) 0x0
0x0000000000000007 (RELA) 0x1ba0
0x0000000000000008 (RELASZ) 744 (bytes)
0x0000000000000009 (RELAENT) 24 (bytes)
0x000000006ffffff9 (RELACOUNT) 20
0x0000000000000017 (JMPREL) 0x1e88
0x0000000000000002 (PLTRELSZ) 2448 (bytes)
0x0000000000000003 (PLTGOT) 0x12928
0x0000000000000014 (PLTREL) RELA
0x0000000000000006 (SYMTAB) 0x340
0x000000000000000b (SYMENT) 24 (bytes)
0x0000000000000005 (STRTAB) 0xfc4
0x000000000000000a (STRSZ) 3032 (bytes)
0x000000006ffffef5 (GNU_HASH) 0xfa8
0x0000000000000019 (INIT_ARRAY) 0x12630
0x000000000000001b (INIT_ARRAYSZ) 72 (bytes)
0x000000000000001a (FINI_ARRAY) 0x12628
0x000000000000001c (FINI_ARRAYSZ) 8 (bytes)
0x000000000000000c (INIT) 0x10f84
0x000000000000000d (FINI) 0x10fa0
0x000000006ffffff0 (VERSYM) 0xda8
0x000000006ffffffe (VERNEED) 0xe88
0x000000006fffffff (VERNEEDNUM) 5
0x0000000000000000 (NULL) 0x0
| 03:24:09 |
Corngood | Maybe you have LD_ vars or nix-ld?
In any case it's not patched, which is going to be a problem for building. | 03:28:57 |
Whovian9369 | (In case it matters, I used readelf from nixpkgs#llvmPackages_21.bintools) | 03:29:12 |
Corngood | Does build.sh pull in dependencies? Maybe it should be in preBuild. | 03:29:57 |
Corngood | Then it wouldn't get run in fetch, and maybe in a real build the executable would be patched | 03:30:22 |
Corngood | There are definitely projects using nuke in nixpkgs, and I don't remember them having this problem. | 03:31:35 |
Whovian9369 | I believe part of the issue there is that it's using Nuke for part of the build (for CodeGen) and Dotnet for the rest. | 03:32:44 |
Corngood | But why put it in preConfigure rather than preBuild. The restore stuff should stay in preConfigure | 03:35:09 |
Corngood | * But why put it in preConfigure rather than preBuild? The restore stuff should stay in preConfigure | 03:35:24 |
Whovian9369 | Can't say that I remember, but I'll see what I can mess with. Thanks! | 03:35:45 |
Whovian9369 | Here's what I'm trying out now:
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
'';
preBuild = ''
patchShebangs --build build.sh
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
./build.sh Codegen --configuration ${buildType}
'';
| 03:36:50 |
Whovian9369 | That fixes it in fetch-deps at least, so let's see if a normal nix build succeeds here. | 03:37:15 |
Whovian9369 | Oh I switched it back to NET 8, whoops - Lemme try a second time. | 03:37:34 |
Corngood | You probably need to keep the restore call in configure and move only the build.sh | 03:38:08 |
Whovian9369 | Good idea, thank ya | 03:38:41 |
Corngood | Fetch stops after configure by default | 03:38:53 |
Whovian9369 | Well fetch-deps didn't yell, which is good. | 03:39:59 |
Whovian9369 | Build itself failed.
preConfigure = ''
dotnet --version > DotnetCliVersion.txt
for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
'';
preBuild = ''
patchShebangs --build build.sh
./build.sh Codegen --configuration ${buildType}
'';
...
Executing dotnetBuildHook
patching script interpreter paths in build.sh
build.sh: interpreter directive changed from "#!/usr/bin/env bash" to "/nix/store/q7sqwn7i6w2b67adw0bmix29pxg85x3w-bash-5.3p3/bin/bash"
GNU bash, version 5.3.3(1)-release (x86_64-pc-linux-gnu)
Microsoft (R) .NET Core SDK version 9.0.305
You must install or update .NET to run this application.
App: /build/source/build/bin/Debug/_build
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '8.0.0' (x64)
.NET location: /nix/store/pkvy24cwwrsg3q3rqkhak8k6j98ns5gy-dotnet-sdk-9.0.305/share/dotnet
The following frameworks were found:
9.0.9 at [/nix/store/pkvy24cwwrsg3q3rqkhak8k6j98ns5gy-dotnet-sdk-9.0.305/share/dotnet/shared/Microsoft.NETCore.App]
Learn more:
https://aka.ms/dotnet/app-launch-failed
To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=8.0.0&arch=x64&rid=linux-x64&os=linux
| 03:42:20 |
Whovian9369 | Wait, why is it trying to look for Net 8? Guess I need to try and troubleshoot that... | 03:42:48 |
Corngood | That executable must target net8, but it should run on 9. Maybe roll forward is disabled or something? | 03:44:47 |
Corngood | I still don't really understand where the executable is coming from. | 03:45:11 |
Whovian9369 | It's coming from build/_build.csproj as a CodeGen step before running the "real" build. | 03:46:48 |
Whovian9369 | [whovian@nixos-wsl:/tmp/wat/nix/hactoolnet/source]$ runPhase buildPhase
Running phase: buildPhase
Executing dotnetBuildHook
...
/nix/store/pkvy24cwwrsg3q3rqkhak8k6j98ns5gy-dotnet-sdk-9.0.305/share/dotnet/sdk/9.0.305/Sdks/Microsoft.NET.Sdk/targets/Microsoft.PackageDependencyResolution.targets(266,5): error NETSDK1005: Assets file '/tmp/wat/nix/hactoolnet/source/src/hactoolnet/obj/project.assets.json' doesn't have a target for 'net9.0'. Ensure that restore has run and that you have included 'net9.0' in the TargetFrameworks for your project. [/tmp/wat/nix/hactoolnet/source/src/hactoolnet/hactoolnet.csproj]
0 Warning(s)
1 Error(s)
...
So it definitely isn't expecting net8 at all, great. Guess I'm looking deeper! 😅
| 03:48:18 |
Corngood | https://learn.microsoft.com/en-us/dotnet/core/versions/selection#precedence | 03:48:54 |
Whovian9369 | Yeah it seems to be setting TargetFramework to net8.0 in build/_build.csproj so I'll need to patch that and possibly update Nuke.Common in the same csproj
<PackageReference Include="Nuke.Common" Version="8.0.0" />
| 03:49:50 |
Corngood | Try the roll forward options from that link first. It may be fine to target 8 and run on 9 | 03:51:02 |
Whovian9369 | Would you say the best solution is likely via env.DOTNET_ROLL_FORWARD = true? | 03:51:35 |
Whovian9369 | * Would you say the best solution is likely via env.DOTNET_ROLL_FORWARD = "LatestMajor";? | 03:51:57 |
Corngood | I'd give that a try at least | 03:52:35 |
Whovian9369 | Good news is that Nuke ran, but throws...
...
Building stage 2 codegen project.
23:53:31 [ERR] Target Codegen has thrown an exception
System.PlatformNotSupportedException: BinaryFormatter serialization and deserialization have been removed. See https://aka.ms/binaryformatter for more information.
at System.Runtime.Serialization.Formatters.Binary.BinaryFormatter.Serialize(Stream serializationStream, Object graph)
at Nuke.Common.Tooling.SettingsEntityExtensions.NewInstance[T](T settingsEntity) in /_/source/Nuke.Tooling/SettingsEntity.NewInstance.cs:line 23
at Nuke.Common.Tools.DotNet.DotNetRunSettingsExtensions.SetProjectFile[T](T toolSettings, String projectFile) in /_/source/Nuke.Common/Tools/DotNet/DotNet.Generated.cs:line 5507
at LibHacBuild.Build.RunCodegenStage2() in /tmp/wat/nix/hactoolnet/source/build/Build.cs:line 658
at LibHacBuild.Build.<get_Codegen>b__70_1() in /tmp/wat/nix/hactoolnet/source/build/Build.cs:line 206
at Nuke.Common.Execution.BuildExecutor.<>c.<Execute>b__4_2(Action x) in /_/source/Nuke.Build/Execution/BuildExecutor.cs:line 119
at System.Collections.Generic.List`1.ForEach(Action`1 action)
at Nuke.Common.Execution.BuildExecutor.Execute(NukeBuild build, ExecutableTarget target, IReadOnlyCollection`1 previouslyExecutedTargets, Boolean failureMode) in /_/source/Nuke.Build/Execution/BuildExecutor.cs:line 119
...
| 03:53:56 |