| 24 Feb 2026 |
 alexfmpe |
these 399 derivations will be built:
| 12:41:46 |
| alexfmpe | ouch | 12:41:51 |
| alexfmpe | oh, it's mostly cargo packages | 12:42:07 |
 crazychaoz | sry >.< | 12:42:33 |
| alexfmpe | that's fine, I just had assumed I was going to be gcc/clang or something from the build count | 12:43:40 |
| alexfmpe | "will be built" includes /nix/store/nmdiyb745sphcs3x0c8nnx6r82wy6mkn-pthreads-w32-x86_64-w64-mingw32-2.9.1.drv | 12:44:18 |
| alexfmpe | which built just fine individually | 12:44:29 |
| alexfmpe | which built furiously quick, some 300+ in a minute | 12:47:10 |
| crazychaoz | tons of caching | 12:47:55 |
| crazychaoz | the individual drv are just the downloaded sources | 12:48:42 |
| alexfmpe | that explains why backtor-deps is doing what looks like a normal cargo build | 12:49:02 |
| alexfmpe | well, build finished just fine | 12:49:26 |
| crazychaoz | but the pthreads already went through? | 12:49:35 |
| crazychaoz | alright | 12:49:46 |
| crazychaoz | my system is cursed | 12:49:51 |
| alexfmpe | yeah when I saw it in dry-run, I individually called nix-build on it | 12:49:52 |
| alexfmpe | don't actually have wine here to run, but seems fine
$ tree result
result
└── bin
└── backtor.exe
$ file result/bin/backtor.exe
result/bin/backtor.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows
| 12:50:22 |
| alexfmpe | could be broken on linux, I can test tomorrow or so | 12:50:49 |
| crazychaoz | thanks for the invested time ^^ | 12:51:45 |
| 25 Feb 2026 |
 rosssmyth | tbh you are holding it wrong a bit.
You are manually doing the splicing which may be messing it up. You are declaring that you are building for x64 linux, so that is what stdenv thinks.
You put compilers into depsBuildBuild, which stdenv thinks "this is a compiler that runs on build (x64 linux) and targets build (x64 linux)". I'm not sure if stdenv.cc is spliced though. It may not be.
But you are telling stdenv that the headers will be used for a linux host, so it refuses to compile. This was most likely "broken" by me here
https://github.com/NixOS/nixpkgs/pull/430165
But in reality I would call this, mostly "working as intended" | 15:06:04 |
| rosssmyth | The "proper" way of doing this is making a derivation function and pkgsCross.mingwW64.callPackageing it | 15:06:38 |
| rosssmyth | * tbh you are holding it wrong a bit.
You are manually doing the splicing which may be messing it up. You are declaring that you are building for x64 linux, so that is what stdenv thinks.
You put compilers into depsBuildBuild, which stdenv thinks "this is a compiler that runs on build (x64 linux) and targets build (x64 linux)". I'm not sure if stdenv.cc is spliced though. It may not be.
But you are telling stdenv that the headers will be used for a linux host, so it refuses to compile. This was most likely "broken" by me here
https://github.com/NixOS/nixpkgs/pull/430165
But in reality I would call this, mostly, "working as intended" | 15:08:01 |
 Artturin | Theres no manual slicing in that, instead they're not getting spliced packages at all | 15:23:19 |
| Artturin | * Theres no manual splicing in that, ~~instead they're not getting spliced packages at all~~ disregard that, I forgot that pkgs is now spliced | 15:24:35 |
| Artturin | .cc isn't spliced because it's a derivation inside a derivation | 15:25:38 |
| rosssmyth | makes sense | 15:26:31 |
| Artturin | So actually now that pkgs is spliced the issue is that they're spliced now :D | 15:27:31 |
| Artturin | To not splice you need to be explicit pkgsCross.mingwW64.pkgsBuildHost.windows.pthreads. This will get rid of the error | 15:28:57 |
| crazychaoz | it did not get rid of my error sadly, could anybody test my build please? | 16:00:10 |
 dramforever | pkgsCross.mingwW64.pkgsHostTarget.windows.pthreads | 16:05:08 |
