| 26 Feb 2026 |
 rosssmyth | * Which I never use (on Windows) cause mingw mostly sucks | 20:12:18 |
| rosssmyth | I will give it a look though | 20:12:38 |
 dramforever | [nix-shell:~]$ x86_64-w64-mingw32-gcc -l:libpthread.a -o test x.c
[nix-shell:~]$ file test.exe
test.exe: PE32+ executable (console) x86-64 (stripped to external PDB), for MS Windows, 10 sections
| 20:13:14 |
| dramforever | it sure looks like it should work | 20:13:23 |
| dramforever | without additional arguments to the linker | 20:13:31 |
| rosssmyth | Do we use gcc as the linker driver with rustc, or ld directly? | 20:14:08 |
 emily | tbf I assume the MSVC target doesn't use a pthreads emulation library. | 20:14:35 |
| emily | I hope? | 20:14:36 |
| dramforever | both work | 20:14:40 |
| dramforever | * both ld and gcc work | 20:14:49 |
| dramforever | i think we should be using gcc | 20:14:52 |
| rosssmyth | Yes | 20:15:03 |
| dramforever | so like obviously my worry is not that it's not sending pthreads into rustc | 20:15:32 |
| dramforever | but that we've managed to have it use the wrong linker | 20:15:44 |
| emily | stop doing MinGW / Windows was not supposed to be given GCC / etc. | 20:15:54 |
| rosssmyth | rustc just tells the linker to use it | 20:15:54 |
| emily | wanted to run the GNU toolchain on a Microsoft platform anyway for a laugh? we had a tool for that: it was called DJGPP | 20:16:19 |
| rosssmyth | Rustc itself doesn't need to know where it is | 20:16:21 |
