In reply to @samuel:mnzn.dev
Any plans on upgrading to .NET 10 RC1?

Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?

Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build
(Then the message is about stub-ld etc)

Here to cause trouble again - I'm trying to bump a project from NET 8 to NET 9 in a derivation (without code changes, dev says it should work), but that Nuke build process seems to fail due to using a dynamically linked executable... Hapen to have any immediate ideas?

Could not start dynamically linked executable: /tmp/fetch-deps-hactoolnet-2024.08.29.Pzmhk6/source/build/bin/Debug/_build

(Then the message is about stub-ld etc)

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

preConfigure = ''
  dotnet --version > DotnetCliVersion.txt
  patchShebangs --build build.sh
  for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
  ./build.sh Codegen --configuration ${buildType}
'';

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
preConfigure = ''
  dotnet --version > DotnetCliVersion.txt
  patchShebangs --build build.sh
  for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
  ./build.sh Codegen --configuration ${buildType}
'';
}

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
  preConfigure = ''
    dotnet --version > DotnetCliVersion.txt
    patchShebangs --build build.sh
    for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
    ./build.sh Codegen --configuration ${buildType}
  '';
}

In reply to @whovian9369:matrix.org

Alternatively, is there a way to keep the in-progress /tmp/fetch-deps-... path even after a failed run? I feel like that would be good for testing.

---

The same process works fine on Net 8 but not Net 9, so I'm stumped from what I can tell.

{
  preConfigure = ''
    dotnet --version > DotnetCliVersion.txt
    patchShebangs --build build.sh
    for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done
    ./build.sh Codegen --configuration ${buildType}
  '';
}

It works on Net 8 as expected, but trying the otherwise same derivation with the Net 9 SDK threw that error, for whatever reason. I'll probably have to try it with Net 8 (via fetch-drv?) and see how much the ldd output differs for these _build binaries.

Here's the Net 9 ldd on _build for example:

$  ldd _build
        linux-vdso.so.1 (0x00007ffffa5f8000)
        libpthread.so.0 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libpthread.so.0 (0x00007aef94629000)
        libdl.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libdl.so.2 (0x00007aef94624000)
        libstdc++.so.6 => not found
        libm.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libm.so.6 (0x00007aef9453c000)
        libgcc_s.so.1 => /nix/store/f6famnry0piih1d3hh6y73fxx05jxsa8-xgcc-14.3.0-libgcc/lib/libgcc_s.so.1 (0x00007aef9450e000)
        libc.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6 (0x00007aef94200000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007aef94645000)

Did MS or an Nixpkgs remove linking against libstdc between Net 8 and Net 9? That's the only issue that I can immediately find, for example...

It works on Net 8 as expected, but trying the otherwise same derivation with the Net 9 SDK threw that error, for whatever reason. I'll probably have to try it with Net 8 (via fetch-drv?) and see how much the ldd output differs for these _build binaries.

Here's the Net 9 ldd on _build for example:

$  ldd _build
        linux-vdso.so.1 (0x00007ffffa5f8000)
        libpthread.so.0 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libpthread.so.0 (0x00007aef94629000)
        libdl.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libdl.so.2 (0x00007aef94624000)
        libstdc++.so.6 => not found
        libm.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libm.so.6 (0x00007aef9453c000)
        libgcc_s.so.1 => /nix/store/f6famnry0piih1d3hh6y73fxx05jxsa8-xgcc-14.3.0-libgcc/lib/libgcc_s.so.1 (0x00007aef9450e000)
        libc.so.6 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib/libc.so.6 (0x00007aef94200000)
        /lib64/ld-linux-x86-64.so.2 => /nix/store/8p33is69mjdw3bi1wmi8v2zpsxir8nwd-glibc-2.40-66/lib64/ld-linux-x86-64.so.2 (0x00007aef94645000)

Did MS or an Nixpkgs remove linking for libstdc++.so.6 between Net 8 and Net 9? That's the only issue that I can immediately find, for example...

This executable must come from a nuget package?

I believe the binary comes from for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done

But how is it finding any of those libs?
Honestly, that's a good question that I don't have an answer to.

This executable must come from a nuget package?

I believe the binary comes from for rid in $dotnetRuntimeIds; do dotnet restore --runtime "$rid" "build/_build.csproj"; done

But how is it finding any of those libs?

Honestly, that's a good question that I don't have an answer to.