| 26 Feb 2026 |
 K900 | windows is a general namespace for Windows specific packages | 14:25:46 |
| K900 | There's no pthreads package at top level because it's normally provided by libc | 14:25:54 |
 crazychaoz | obviously, but i am compiling with pkgsCross.mingwW64.stdenv, why do i have to give additional information as to where the windows specific headers should end up at?
i have had issues before with tools that need to get compiled on host&target (eg. protobuf) but here the situation should be clear? i run compilation for windows, with win pthreads, why would i ever want to compile windows.pthreads for non windows targets?
| 14:32:30 |
| K900 | Look, that's just how nixpkgs is structured | 14:34:43 |
| crazychaoz | ack | 14:38:01 |
 rosssmyth | I would like to fix it, but testing and implementing cross is annoying due to different people telling me different things of what to do and what not to do. | 15:42:06 |
| rosssmyth | * I would like to fix it, but testing and implementing it is annoying due to different people telling me different things of what to do and what not to do. | 15:42:13 |
 Artturin | pthreads should be in buildInputs | 15:44:00 |
| Artturin | The reason it works for you is that you're not using a cross stdenv so strictDeps isn't enabled | 15:44:19 |
| Artturin | * The reason nativeBuildInputs works for you is that you're not using a cross stdenv so strictDeps isn't enabled | 15:44:35 |
| Artturin | pkgsCross.mingwW64.windows.pthreads you can put this in buildInputs and it won't need pkgsHostTarget | 15:47:15 |
| Artturin | * pkgsCross.mingwW64.windows.pthreads you can put this in buildInputs and it won't need a explciit pkgsHostTarget | 15:47:26 |
| Artturin | * pkgsCross.mingwW64.windows.pthreads you can put this in buildInputs and it won't need a explicit pkgsHostTarget | 15:47:38 |
|  Aoinoikaz joined the room. | 15:48:41 |
