Would an additional platform check GHC version for Windows Subsystem for Linux make sense?

[NickSeagull]

Issue description

Currently, if a user tries to use GHC8+ in WSL, when using the versions provided by nixpkgs or by Stackage, it simply fails on compile anything as it tried to allocate more memory than it is able to (1TB+).

This is because GHC 8.0's new block-structured heap for 64-bit platforms. From the GHC 8.0.1 release notes:

We have a shiny new two-step memory allocator for 64-bit platforms (see Trac #9706). In addition to simplifying the runtime system’s implementation this may significantly improve garbage collector performance. Note, however, that Haskell processes will have an apparent virtual memory footprint of a terabyte or so. Don’t worry though, most of this amount is merely mapped but uncommitted address space which is not backed by physical memory.

There is a whole Github thread for discussing this on MS BashOnWindows repo.

Would it make sense for nixpkgs to include a "fixed" version of GHC8, so one is able to run it from WSL?

This is solved easily, as described in this comment:

git clone -b ghc-8.0.2-release --recursive git://git.haskell.org/ghc.git ghc-8.0.2
cd ghc-8.0.2
./boot
./configure --disable-large-address-space #can set --prefix=... here
make -j8 #-j(number-of-threads)
sudo make install

As I can see, it is already being checked for iOS in this file for ghc-8.0.2.

Would it make sense to add another check for WSL here?

Steps to reproduce

Try to compile any project that depends on GHC8+ on WSL.

Technical details

• System: WSL

$ cat /proc/version
Linux version 4.4.0-43-Microsoft ([email protected]) (gcc version 5.4.0 (GCC) ) #1-Microsoft Wed Dec 31 14:42:53 PST 2014

• Nix version: nix-env (Nix) 1.11.13
• Nixpkgs version: "17.09pre112229.e619ace733"
• Sandboxing enabled: grep: /etc/nix/nix.conf: No such file or directory

[vcunat]

/cc @peti.

To me personally, WSL itself doesn't seem worth building all Haskell stuff twice on Hydra, and having --disable-large-address-space for everyone would decrease GC performance by ~8 %. I wonder if this would be a good candidate for some hack replacing the runtime without recompiling, e.g. via pkgs.replaceDependency.

[peti]

I don't understand the technical details behind this request. What is WSL? Is that a separate platform in Nixpkgs? And if so, what is it called?

[vcunat]

@peti: it's about the linux-inside-windows situation: https://msdn.microsoft.com/en-us/commandline/wsl/install_guide Using the same linux binaries should usually just work there.

[peti]

So it's not a separate platform in Nixpkgs?

[vcunat]

Yes, my understanding is that it doesn't need to be a separate platform, in general. (I don't use Windows, so I've never really tried WSL...)

[NickSeagull]

Yes, a different platform is kinda overkill. The way to currently detect if the user is running Linux or not is by inpecting the /proc/version file and see if it contains the string Microsoft in it.

I was thinking about adding a check for GHC8+

[peti]

I think it would be feasible to add a boolean argument to the GHC Nix expression that enables/disables use of large-address-space at compile-time so that people who want that can override the default choice easily. Disabling it for all of Linux by default doesn't sound like a good idea to me.

@NickSeagull, does this answer your question?

[NickSeagull]

Definitely, disabling it for all of Linux is not feasible at all.

The situation that I'm thinking of is:

• User wants to create package A which depends on package B
• The package B depends on GHC8+, but its author didnt enable the large-address-space flag.

How the user would proceed on enabling that flag, and furthermore, could they dynamicly enable it in their default.nix file? I think it would be interesting if the check was automatic @peti

[peti]

I think you'll find that https://nixos.org/nixpkgs/manual/#sec-overrides and https://nixos.org/nixpkgs/manual/#users-guide-to-the-haskell-infrastructure provide a wealth of information towards that end. If you have any specific questions, then it's probably best to ask on the nix-devel mailing list or -- even better -- in the #nixos IRC channel. The bug tracker seems like it's the wrong place for that kind of conversation.

[NickSeagull]

In case someone comes from Google looking for a working version of GHC for WSL, I've created a repository with overrides for different packages that are meant to be "patched" somehow for working properly in WSL. https://github.com/NickSeagull/wsl-nixpkgs