get rid of mcfgthread on Windows #180

New Issue

sb10q · 2022-02-07T11:45:00+08:00

sb10q commented

2022-02-07 11:45:00 +08:00

used by LLVM, comes from nixpkgs implementation of std::thread for Windows
suspected of causing #176
it cannot be linked statically and creates one more DLL dependency to manage

* used by LLVM, comes from nixpkgs implementation of ``std::thread`` for Windows * suspected of causing https://git.m-labs.hk/M-Labs/nac3/issues/176 * it cannot be linked statically and creates one more DLL dependency to manage

sb10q commented

2022-02-07 11:49:14 +08:00

Alternatives:

https://github.com/meganz/mingw-std-threads - doesn't work without a fight because CMake. See https://stackoverflow.com/questions/37358856/does-mingw-w64-support-stdthread-out-of-the-box-when-using-the-win32-threading
Ideally we would get rid of std::thread in LLVM completely, but as usual LLVM doesn't care at all about bloat and dependencies, and seems to require extensive patching to achieve that.

Alternatives: * https://github.com/meganz/mingw-std-threads - doesn't work without a fight [because CMake](https://twitter.com/CmakeHate). See https://stackoverflow.com/questions/37358856/does-mingw-w64-support-stdthread-out-of-the-box-when-using-the-win32-threading * Ideally we would get rid of ``std::thread`` in LLVM completely, but as usual LLVM doesn't care at all about bloat and dependencies, and seems to require extensive patching to achieve that.

pca006132 commented

2022-02-07 11:53:05 +08:00

What does LLVM use when it build on Windows/in the legacy compiler build script? Something provided by Visual C++?

sb10q commented

2022-02-07 11:53:52 +08:00

Yes, and I would assume that Visual C++ provides std::thread.

Yes, and I would assume that Visual C++ provides ``std::thread``.

sb10q commented

2022-02-07 11:57:57 +08:00

Patching LLVM might not be too bad. As far as I can tell all the thread-related functions are completely unnecessary for our purposes, and they are encapsulated in the Support libraries in LLVM. A hacky way out could be to replace all the problematic functions there with dummies that do nothing.

Eventually we should get rid of LLVM itself.

Patching LLVM might not be too bad. As far as I can tell all the thread-related functions are completely unnecessary for our purposes, and they are encapsulated in the ``Support`` libraries in LLVM. A hacky way out could be to replace all the problematic functions there with dummies that do nothing. Eventually we should get rid of LLVM itself.

sb10q commented

2022-02-10 11:24:47 +08:00

For some reason this causes cmake not to find gcc:

diff --git a/flake.nix b/flake.nix
index f4aa84c..fe51545 100644
--- a/flake.nix
+++ b/flake.nix
@@ -150,7 +150,12 @@
       };
 
       packages.x86_64-w64-mingw32 = rec {
-        llvm-nac3 = pkgs-mingw.callPackage "${self}/llvm" { inherit (pkgs) llvmPackages_13; };
+        llvm-nac3 = pkgs-mingw.callPackage "${self}/llvm" {
+          stdenv = pkgs-mingw.overrideCC pkgs-mingw.stdenv (pkgs-mingw.stdenv.cc.cc.overrideAttrs(oa: {
+            configureFlags = (pkgs-mingw.lib.lists.remove "--enable-threads=mcf" oa.configureFlags) ++ ["--enable-threads=win32"];
+          }));
+          inherit (pkgs) llvmPackages_13;
+        };
         nac3artiq = pkgs-mingw.python3Packages.toPythonModule (
           pkgs-mingw.rustPlatform.buildRustPackage {
             name = "nac3artiq";

For some reason this causes cmake not to find gcc: ``` diff --git a/flake.nix b/flake.nix index f4aa84c..fe51545 100644 --- a/flake.nix +++ b/flake.nix @@ -150,7 +150,12 @@ }; packages.x86_64-w64-mingw32 = rec { - llvm-nac3 = pkgs-mingw.callPackage "${self}/llvm" { inherit (pkgs) llvmPackages_13; }; + llvm-nac3 = pkgs-mingw.callPackage "${self}/llvm" { + stdenv = pkgs-mingw.overrideCC pkgs-mingw.stdenv (pkgs-mingw.stdenv.cc.cc.overrideAttrs(oa: { + configureFlags = (pkgs-mingw.lib.lists.remove "--enable-threads=mcf" oa.configureFlags) ++ ["--enable-threads=win32"]; + })); + inherit (pkgs) llvmPackages_13; + }; nac3artiq = pkgs-mingw.python3Packages.toPythonModule ( pkgs-mingw.rustPlatform.buildRustPackage { name = "nac3artiq"; ```

occheung commented

2022-02-14 10:35:41 +08:00

Appled this patch to LLVM to remove std::thread dependency.
Built successfuly on linux variant, but got "undefined reference to __mingwthr_key_dtor" on Windows build when compiling nac3artiq. LLVM alone can be built on Windows.
Also, there might be some funny stuff going on with the cmake config, I should not need to touch some of the macro-build-flags in LLVM.

Appled this patch to LLVM to remove `std::thread` dependency. Built successfuly on linux variant, but got "undefined reference to `__mingwthr_key_dtor`" on Windows build when compiling `nac3artiq`. LLVM alone can be built on Windows. Also, there might be some funny stuff going on with the cmake config, I should not need to touch some of the macro-build-flags in LLVM.

remove-std-thread.diff

182 KiB

occheung commented

2022-03-16 12:07:05 +08:00

Found another definition of __mingwthr_key_dtor in mingwrt, which is not a stub.
However, the pkgsCross.mingw32.windows.mingwrt build fails.

make: *** No rule to make target 'w32api.h.in', needed by 'w32api.h'.  Stop.

w32api is not listed as a build dependency of mingwrt in nixpkgs. Anyway, w32api build also fails.
https://github.com/NixOS/nixpkgs/issues/91983

Found another definition of `__mingwthr_key_dtor` in `mingwrt`, which is not a stub. However, the `pkgsCross.mingw32.windows.mingwrt` build fails. ``` make: *** No rule to make target 'w32api.h.in', needed by 'w32api.h'. Stop. ``` `w32api` is not listed as a build dependency of `mingwrt` in nixpkgs. Anyway, `w32api` build also fails. https://github.com/NixOS/nixpkgs/issues/91983

sb10q commented

2022-03-21 23:48:53 +08:00

#232

sb10q closed this issue

2022-03-21 23:48:54 +08:00

Sign in to join this conversation.