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.

$  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