`threads` dependency should not be "-lpthread" when using MinGW if using mcfgthread about meson HOT 6 OPEN

We don't actually use -l pthread, we use -pthread? Of course internally that's going to invoke -l pthread.

What does mcfgthread want in order to be used? I assume it can't possibly require "no extra argument" because then nothing actually instructs the code to use it. And that's a problem unless the compiler internally adds the requisite arguments via the spec file, as pthread is currently handled.

from meson.

We don't actually use -l pthread, we use -pthread? Of course internally that's going to invoke -l pthread.

Ah yes. I was just being silly reading

/nix/store/10lwr6m112g609x4qj8k4awl8pyk4qkh-x86_64-w64-mingw32-binutils-2.40/bin/x86_64-w64-mingw32-ld: cannot find -lpthread: No such file or directory

What does mcfgthread want in order to be used?...

@eli-schwartz To be honest, I am not really sure. I am not passing -lpthread and I am using std::thread, etc. The GCC libs are configure-time backed to use mcfgthread, so maybe that deals with it?

from meson.

What I would hope is that if it's configure-time changed to use mcfgthread then the specs would be changed to link with -l mcfgthread instead of -l pthread (it does look like mcfgthread provides a DLL!).

Do you need e.g. -D_REENTRANT defined in order to use mcfgthread?

from meson.

I don't know because I added mcfgthead to Nixpkgs to get std::thread in 2019 (?) and other people maintained it since. It is all automatic as far as I can tell :)

from meson.

Now that NixOS/nix#10855 is merged, I think it should be easier to try this out by making the threads dep unconditional and doing nix-build -A packages.x86_64-linux.nix-util-x86_64-w64-mingw32.dev

from meson.