| 26 Feb 2026 |
 rosssmyth | Same way as using musl and glibs | 20:20:13 |
 emily | anyway I think someone should ask rustc what linker command it's actually calling | 20:20:23 |
| rosssmyth | * Same way as using musl and glibc | 20:20:27 |
| rosssmyth | It's probably in our rustc wrapper somewhere I'd guess | 20:20:44 |
| rosssmyth | I'll poke around | 20:20:47 |
| emily | isn't there just a flag that makes it print the command it runs? | 20:21:28 |
| emily | I thought it did that whenever it failed even | 20:21:34 |
| rosssmyth | Yeah | 20:21:37 |
| rosssmyth | rustc -V or something | 20:21:44 |
| rosssmyth | rustc --print link-args but you need to supply it with some files to munch on | 20:24:41 |
 dramforever | i can't compile ripgrep rn because it depends on ... arm64ec wine when crossing from aarch64-linux? which we don't have | 20:26:20 |
| dramforever | but pkgsCross.mingwW64.bonk works for me | 20:26:29 |
| dramforever | * i can't compile ripgrep rn because it depends on ... arm64ec wine plus an x86_64 emulator when crossing from aarch64-linux? which we don't have | 20:26:47 |
| dramforever | did this magically get fixed in the few months...? | 20:27:20 |
| dramforever | * did this magically get fixed in the few months since that PR...? | 20:27:26 |
| emily | iirc we have some awful thing where you can pick between five different thread implementations for MinGW? | 20:27:35 |
| emily | so maybe that's relevant | 20:27:38 |
| rosssmyth | I removed most of those, so it should only use the real one most of the time except in one weird case | 20:28:01 |
| rosssmyth | Which idk why it is needed, but I just didn't touch it. | 20:28:21 |
| rosssmyth | Using a weird windows pthreads from 2010 that hasn't been updated since 2013 is not actually load bearing it turns out | 20:32:22 |
| emily | it's a Nixpkgs edge case so either one guy in 2014 used it once and it never even worked in-tree or you will break every single setup if you change it | 20:32:27 |
| rosssmyth | Yes. Which is why I didn't touch it. | 20:32:40 |
| rosssmyth | If you want to see where it is used just run rg mcfgthreads | 20:33:19 |
| emily | yeah I have run into that before because of … GCC stuff or whatever | 20:33:32 |
| emily | and been like what is this | 20:33:35 |
| emily | threads =
lib.optionalAttrs (stdenv.hostPlatform.isMinGW && !(stdenv.hostPlatform.useLLVM or false))
{
# other possible values: win32 or posix
model = "mcf";
# For win32 or posix set this to null
package = windows.mcfgthreads;
};
are you sure this isn't used?
| 20:34:06 |
| dramforever | i am so confused | 20:34:07 |
| emily | I think threads is a load-bearing part of the bootstarp | 20:34:15 |
| rosssmyth | Probably! | 20:34:25 |
| emily | threadsCross =
if !lib.systems.equals stdenv.targetPlatform stdenv.buildPlatform then
targetPackages.threads or pkgs.threads
else
{ };
| 20:34:43 |
