Cannot install GHC through stack on NixOS

[h2000Stefanov]

stack setup gives me this error:

# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.
# For some reason, this means the DLLs end up non-executable, which means
# executables that use them just segfault.
/run/current-system/sw/bin/install -c -m 755 -d  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts"
for i in  rts/dist/build/libHSrts.a rts/dist/build/libHSrts_p.a rts/dist/build/libHSrts-ghc8.4.3.so rts/dist/build/libHSrts_l.a rts/dist/build/libHSrts_debug.a rts/dist/build/libHSrts_thr.a rts/dist/build/libHSrts_thr_debug.a rts/dist/build/libHSrts_thr_l.a rts/dist/build/libHSrts_thr_p.a rts/dist/build/libHSrts_debug-ghc8.4.3.so rts/dist/build/libHSrts_thr-ghc8.4.3.so rts/dist/build/libHSrts_thr_debug-ghc8.4.3.so rts/dist/build/libHSrts_l-ghc8.4.3.so rts/dist/build/libHSrts_thr_l-ghc8.4.3.so rts/dist/build/libffi.so.7.1.0 rts/dist/build/libffi.so.7 rts/dist/build/libffi.so rts/dist/build/libCffi.a rts/dist/build/libCffi_p.a rts/dist/build/libCffi_l.a rts/dist/build/libCffi_debug.a rts/dist/build/libCffi_thr.a rts/dist/build/libCffi_thr_debug.a rts/dist/build/libCffi_thr_l.a rts/dist/build/libCffi_thr_p.a; do case $i in *.a) /run/current-system/sw/bin/install -c -m 644  $i  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts"; true  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts"/`basename $i` ;; *.dll) /run/current-system/sw/bin/install -c -m 755  $i  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts" ; strip  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts"/`basename $i` ;; *.so) /run/current-system/sw/bin/install -c -m 755  $i  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts" ;; *.dylib) /run/current-system/sw/bin/install -c -m 755  $i  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts";; *) /run/current-system/sw/bin/install -c -m 644  $i  "/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3/rts"; esac; done
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/ghc-prim dist-install "strip" '' '/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3' '/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/lib/ghc-8.4.3' '/home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/share/doc/ghc-8.4.3/html/libraries' 'v p dyn'  

utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist: line 3: /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/utils/ghc-cabal/dist-install/build/tmp/ghc-cabal: No such file or directory
make[1]: *** [ghc.mk:1001: install_packages] Error 127
make: *** [Makefile:51: install] Error 2

                  
Error: Error encountered while installing GHC with
         make install
         run in /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/ghc-8.4.3/
       
       The following directories may now contain files, but won't be used by stack:
         - /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3.temp/
         - /home/stefanov/.stack/programs/x86_64-linux/ghc-8.4.3/

Now,I have no idea how to fix this.Install GHC through nixpkgs maybe?Any possible workaround?

[fex42]

same problem here

[twashing]

+1 from me. I detailed my issue in an SO question here.

Has this problem been investigated? Anything we can do to help?

[mihaimaruseac]

We didn't get a windows+nix machine to investigate this on, unfortunately.

[qrilka]

@mihaimaruseac why do we need Windows? This issue looks to be about NixOS, isn't it?
@twashing looking into your SO question it looks like the problem is about GHC version - 8.6.4 was made available on unstable only 6 days ago - NixOS/nixpkgs-channels@93e4a90
And on my Gentoo with nix on unstable package I get (on attempts after the first one which isn't fast downloading/installing a lot):

qrilka@qdesktop ~ $ stack --nix --resolver=ghc-8.6.4 exec -- ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.6.4

[chrissound]

@qrilka I've just tried that command (I'm running on Nixos) and I get:

stack --nix --resolver=ghc-8.6.4 exec -- ghc --version
error: attribute 'ghc864' missing, at (string):1:61

stack ---version
1.9.3 x86_64 hpack-0.31.2

This might also be helpful in identifying the issue (similar stackoverflow question):
https://stackoverflow.com/a/47922106/1663462

Seems like stack is referencing a newer GHC that wouldn't yet be present in the nixpkgs of a user. So potentially this could be detected and a more helpful error message shown? (I'm just guessing here)

[qrilka]

@chrissound what channel are you on? And what commit? nix-info shows nixpkgs-19.09pre173147.03050e9749e for me, so it's NixOS/nixpkgs-channels@03050e9 which hast 8.6.4, see https://github.com/NixOS/nixpkgs-channels/blob/03050e9749e1548f1648aae5c062c954eaad546e/pkgs/top-level/haskell-packages.nix
Regarding your last suggestion there was a proposal to add something like that in #4539 and I wanted to create a PR for that but unfortunately I couldn't find time for it yet

[mihaimaruseac]

@qrilka I saw

# The .dll case calls STRIP_CMD explicitly, instead of `install -s`, because
# on Win64, "install -s" calls a strip that doesn't understand 64bit binaries.

at start of log and didn't parse further, my bad.

[twashing]

@qrilka I was on NixOS channels/nixos-18.03. I'd since updated that to be on...

$ nix-channel --list
nixpkgs https://nixos.org/channels/nixpkgs-unstable

After an sudo nixos-rebuild switch --upgrade, stack build --nix still gives me the same .../tmp/ghc-cabal: No such file or directory error.

[qrilka]

@twashing would you care to show what nix-shell -p nix-info --run "nix-info -m" outputs for you? BTW on NixOS nix mode is enabled by default in Stack. Also could you show verbose output of stack build? i.e. from stack build --nix -v?

[twashing]

@qrilka I can definitely do that. I'll also include what happens when I run stack new <my-project> new-template, as there's also a parse error there that I find suspicious.

A)

$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 4.14.105, NixOS, 19.03beta171781.91cb80e4397 (Koi)`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.2`
 - channels(root): `"nixos-19.03beta171781.91cb80e4397"`
 - channels(twashing): `""`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

B) Pastebin for $ stack new helloworld new-template

C) Pastebin for $ stack build --nix -v.

[qrilka]

@twashing for such a long traces I'd advise to use gist or other pastebin to keep discussion more readable, thanks in advance.
I think I have found what causes the error in stack new and stack build that you shown - old Stack version . Version 1.6.5 uses Cabal-2.0 and since then new features were introduced by Cabal, e.g. base-noprelude uses leading commas, implemented in haskell/cabal#4953 which came with 2.2. So Stack fails parsing cabal files using new format features.
If you are on NixOS-unstable then you should have version 1.9.3 available. Could you try upgrading Stack?

[twashing]

@qrilka 10-4 on the other stuff.

Defining stack in environment.systemPackages already installs the latest stack (as of this writing).

# run as root

$ stack upgrade
Current Stack version: 1.9.3, available download version: 1.9.3
Skipping binary upgrade, you are already running the most recent version

Yet I'm still suspicious of when creating a new project with stack new ... (output here). This looks like it's giving the same parse error as stack build.

...
Unable to parse cabal file for base-noprelude-4.12.0.0@sha256:dcd5ece10257f79fa16e207d558b31ab3467b205adae5d1976abdee28b1c8b4a,6845: NoParse "reexported-modules" 42

Here's what my entry looks like. Are we able to tweak anything version-wise?

  environment.systemPackages = with pkgs; [
    wget vim emacs file
    pkgs.firefoxWrapper pkgs.chromium

    stack
    tree gnumake which binutils gcc clang coreutils gnutar
    tmux
    silver-searcher
    gitAndTools.gitFull
  ];

[qrilka]

@twashing I don't quite understand how could you have version 1.9.3 being installed and yet logging 1.6.5 in its output? Could it be something happening with your $PATH? You stay you run stack upgrade as a root, could it me that in your user $PATH you have some other version available? Somewhere in your $HOME? E.g. in ~/bin or ~/.local/bin maybe? Could you try stack --version using the same user and env that you run stack build -v with?
Regardind the parse error in stack new and stack build - it's the same error, old Stack fails to parse unsupported features, so no surprises here.