sort out MSYS2 issues on Windows #27

Closed
opened 2020-06-16 18:54:06 +08:00 by sb10q · 5 comments
Owner

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.
Author
Owner

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
Author
Owner

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"; }; } ```
Author
Owner

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.

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.
Author
Owner

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.
Author
Owner

Compiling with VS now.

Compiling with VS now.
sb10q closed this issue 2020-06-24 10:45:45 +08:00
Sign in to join this conversation.
No Label
No Milestone
No Assignees
1 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: M-Labs/nix-scripts#27
No description provided.