sort out MSYS2 issues on Windows #27

New Issue

sb10q · 2020-06-16T18:54:06+08:00

sb10q commented

2020-06-16 18:54:06 +08:00

The new conda packages built with WFVM currently require a MSYS2 installation and alteration of the PATH with:

set PATH=C:\MSYS64\mingw64\bin;%PATH%

Otherwise:

Attempting to load the LLVM DLL in llvmlite fails with a "File not found" error
The binutils tool fail to start. There is no error message printed, the programs just terminate immediately without doing anything.

It is not clear to me how this used to work, at least for binutils which was also built with MSYS2:
https://github.com/m-labs/conda-recipes/blob/master/conda/binutils-or1k-linux/bld.bat

LLVM and llvmlite were built with Visual Studio, but I'd rather avoid this crap if possible. MSYS2 builds appear possible.

There are existing conda packages with the MSYS2 libraries.

The new conda packages built with WFVM currently require a MSYS2 installation and alteration of the PATH with: ```text set PATH=C:\MSYS64\mingw64\bin;%PATH% ``` Otherwise: * Attempting to load the LLVM DLL in llvmlite fails with a "File not found" error * The binutils tool fail to start. There is no error message printed, the programs just terminate immediately without doing anything. It is not clear to me how this used to work, at least for binutils which was also built with MSYS2: https://github.com/m-labs/conda-recipes/blob/master/conda/binutils-or1k-linux/bld.bat LLVM and llvmlite were built with Visual Studio, but I'd rather avoid this [crap](https://hackernoon.com/a-c-hello-world-and-a-glass-of-wine-oh-my-263434c0b8ad) if possible. MSYS2 builds appear possible. There are existing conda packages with the MSYS2 libraries.

sb10q referenced this issue

2020-06-16 18:56:04 +08:00

binutils invocation problem on Windows #28

sb10q commented

2020-06-16 19:19:06 +08:00

Poster

The reason binutils could run without MSYS2 may be this:
8b490035bf
89ef7b7d22

The reason binutils could run without MSYS2 may be this: https://github.com/m-labs/conda-recipes/commit/8b490035bf704366cc7dc5f895e722d045e322d2 https://github.com/m-labs/conda-recipes/commit/89ef7b7d22c1843f365f1073dd84ce82263fa492

sb10q commented

2020-06-16 19:22:43 +08:00

Poster

If we do have to go for the Visual Studio pile of garbage, this may be useful:


{ pkgs ? import <nixpkgs> {} }:

let
  msvc-wine = pkgs.fetchFromGitHub {
    owner = "mstorsjo";
    repo = "msvc-wine";
    rev = "b953f996401c19df3039c04e4ac7f962e435a4b2";
    sha256 = "12rqx0r3d836x4k1ccda5xmzsd2938v5gmrp27awmzv1j3wplfsq";
  };
in
  {
    vs = pkgs.stdenv.mkDerivation {
      name = "vs";

      outputHashAlgo = "sha256";
      outputHashMode = "recursive";
      outputHash = "1ngq7mg02kzfysh559j3fkjh2hngmay4jjar55p2db4d9rkvqh22";

      phases = [ "buildPhase" ];
      buildInputs = [ pkgs.cacert (pkgs.python3.withPackages(ps: [ ps.simplejson ps.six ])) pkgs.msitools ];
      buildPhase = "python ${msvc-wine}/vsdownload.py --accept-license --dest $out";
    };
  }

If we do have to go for the Visual Studio pile of garbage, this may be useful: ```nix { pkgs ? import <nixpkgs> {} }: let msvc-wine = pkgs.fetchFromGitHub { owner = "mstorsjo"; repo = "msvc-wine"; rev = "b953f996401c19df3039c04e4ac7f962e435a4b2"; sha256 = "12rqx0r3d836x4k1ccda5xmzsd2938v5gmrp27awmzv1j3wplfsq"; }; in { vs = pkgs.stdenv.mkDerivation { name = "vs"; outputHashAlgo = "sha256"; outputHashMode = "recursive"; outputHash = "1ngq7mg02kzfysh559j3fkjh2hngmay4jjar55p2db4d9rkvqh22"; phases = [ "buildPhase" ]; buildInputs = [ pkgs.cacert (pkgs.python3.withPackages(ps: [ ps.simplejson ps.six ])) pkgs.msitools ]; buildPhase = "python ${msvc-wine}/vsdownload.py --accept-license --dest $out"; }; } ```

sb10q commented

2020-06-16 19:25:26 +08:00

Poster

And if we want to replace Conda with MSYS2 entirely (not a bad idea considering MSYS2, unlike Conda, has a package manager): I couldn't get PyQt to work with it, the application freezes when it tries to create its first widget.

sb10q commented

2020-06-20 10:37:25 +08:00

Poster

Using msvc-wine is problematic because CMake (used by LLVM) uses the Registry to get information about the Visual Studio installation, and the Registry entries are missing when just copying the files (even though the compiler actually runs fine without them). This behavior is hardcoded in C++ inside CMake and is difficult to change.

With the official Visual Studio installer (which takes over an hour to complete on a Core i9-9900 with NVMe storage and 300MBps internet), CMake goes a bit further but still fails for some reason.

It's remarkable how annoying this VS stuff is. MSYS compilation pretty much worked the first time.

Using msvc-wine is problematic because CMake (used by LLVM) uses the Registry to get information about the Visual Studio installation, and the Registry entries are missing when just copying the files (even though the compiler actually runs fine without them). This behavior is hardcoded in C++ inside CMake and is difficult to change. With the official Visual Studio installer (which takes over an hour to complete on a Core i9-9900 with NVMe storage and 300MBps internet), CMake goes a bit further but still fails for some reason. It's remarkable how annoying this VS stuff is. MSYS compilation pretty much worked the first time.

sb10q commented

2020-06-24 10:45:43 +08:00

Poster

Compiling with VS now.

sb10q closed this issue

2020-06-24 10:45:45 +08:00

sb10q referenced this issue from M-Labs/wfvm

2020-08-19 12:25:13 +08:00

hash mismatch in fixed-output derivation '/nix/store/zldkjq66059l537da7ryzlqh4jv91p5a-RESTRICTDIST-vs' #3

Sign in to join this conversation.