Cross Compiling Haskell to Windows #36200
Comments
Ericson2314
added
6.topic: cross-compilation
👍 Definitely you can just bump mingw-w64 straight up. No one before you has seriously worked with that stuff in years.
This should be correct / not affect you targeting windows? Are you working on mac -> windows too?
This is intended. The binary ghcs are not cross compilers.
Oooo thanks. You obviously know more about this than me, so glad you could be here to catch my mistake :).
👍 Yeah this was some last-minute hack done be somebody a year ago that was never revisited.
I'd be loath to add more
Oh hmm? This is the opposite of the conclusion I came to talking to you on IRC. Did you confirm this after the fact? |
|
@Ericson2314, I'll hopefully have some clean up ready soon.
It's not. And yes I do mac -> windows, and hope linux -> windows just falls out as nixpkgs (linux) support is usually much better than nixpkgs (macos).
Correct, they are not cross compilers. But they are used to build the cross compilers. E.g. I use the 8.2 binary for bootstrapping the cross compiler. And hence I run into that assert.
Right.
I think I did. I believe the core issue is the order in which the |
|
@angerman sorry to not be getting back sooner.
Cool. @LnL7 and I were working on on mac -> linux things that may help insofar that they fix general infra issues. I'll be working on some ios stuff shortly for work, which may also help.
But then they should come from a previous bootstrapping stage (some
Yeah there's quite likely some low hanging fruit to make it work for both without adding some complexity. Just a matter of using the right idioms.
I'm going to check this right now. edit https://github.com/input-output-hk/nix-hs-hello-windows/pull/2/files |
|
|
Will ping you! Added the custom attribute. |
|
What is the state of this? Is this related to the cross compilation support that I can get (in theory) via or is that separate endevour? (I’d be very keen on using nix and cross compilations to make the Windows releases for |
|
JFTR, this currently (b1f767e) fails building GHC, after running for quite some time: |
|
@nomeata We use https://github.com/input-output-hk/haskell.nix for our cross compilation (to windows) needs at IOHK. |
|
So which of the patches https://github.com/input-output-hk/iohk-nix/tree/master/patches/ghc do we need to get into to compile? |
|
I've just discovered https://github.com/input-output-hk/haskell.nix thanks to this issue and I feel like a kid in a candy store. This is very exciting! @angerman is |
|
With this patch, I can actually build the GHC diff --git a/pkgs/development/compilers/ghc/8.6.4.nix b/pkgs/development/compilers/ghc/8.6.4.nix
index 140cea22442..b0dacae5e2a 100644
--- a/pkgs/development/compilers/ghc/8.6.4.nix
+++ b/pkgs/development/compilers/ghc/8.6.4.nix
@@ -31,7 +31,11 @@
, # What flavour to build. An empty string indicates no
# specific flavour and falls back to ghc default values.
- ghcFlavour ? stdenv.lib.optionalString (stdenv.targetPlatform != stdenv.hostPlatform) "perf-cross"
+ ghcFlavour ?
+ stdenv.lib.optionalString
+ (stdenv.targetPlatform != stdenv.hostPlatform)
+ (if stdenv.targetPlatform.isWindows then "perf-cross-ncg" else "perf-cross")
+
}:
assert !enableIntegerSimple -> gmp != null;Not sure how good it is, though. I can build But packages that invoke haddock fail to build: |
|
@albertov: yes it does support TH if you can construct a runner. Our windows cross compilation infrastructure uses wine for this. As a usage example check out input-output-hk/cardano-chain (hint, also check the relevant builds on our hydra instance to see the jobs we define). @nomeata using There are sadly quite a few patches involved. The intention is to upstream them all though. The library issue with windows in nix is mildly annoying. As a general hack you can either try to build as much statically as possible, or collect all .dlls from the dependency closure and copy them over into $out/bin. As a general note: I have absolutely no idea how well the haskell packages in nix are suited for windows cross compilation. They are I believe generated with cabal2nix and as such do not contain any conditionals from the cabal files. They are flattened at generation time and most likely to os=linux and some predefined flags :-( |
|
One more note: I do trust the ncg more than the llvm backend. The ncg is the default backend for almost every ghc build you come across. |
|
Thank you for your contributions. This has been automatically marked as stale because it has had no activity for 180 days. If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity. Here are suggestions that might help resolve this more quickly:
|
stale
bot
added
the
2.status: stale
|
Maybe the title of this PR should include “Windows”? :) |
stale
bot
removed
the
2.status: stale
|
Just gave it a shot with current master, trying to use 8.8.4 from Probably also just a patch I have to get from somehere… but lunch first. |
So the profiling object has too many sections. The best solution for this I could come up with is to disable profiling. |
Ericson2314
changed the title
|
JFTR: After including all of the GHC patches from haskell.nix I got past that stage. |
|
is there any progress on this? Having nix cross compile a haskell program would save me a lot of tedious windows based building. |
As some may already know, I'm working on cross compiling Haskell to Windows using nix.
I'll try to keep track of the issues I run into, and then add the relevant PRs as I manage to
clean them up.
Minor
targetPlatform.isDarwin, which fails.stdenv.targetPlatform == stdenv.hostPlatform, which fails during validation.buildMKin the ghc expressions is wrong and needs to also include the relevant$flavour.mkhsc2hsfrom thenativeGhc, but should use$targetPrefix-hsc2hs.haskellSetupDependsshould come from thebuildPackagespackage set as they are compiled and run by the native compiler.Major
packageOverridesandbuildPackagesdon't play nice together. Injecting a customghcviaconfigdoesn't work anymore, asbuildPackagesis fixed prior to the overrides being applied, andbuildPackagesdoesn't see any added packages from thepackageOverrides.I might be missing some philosophical foundation with respect to nix here. Please bear with me and help me better understand.
/cc @Ericson2314
The text was updated successfully, but these errors were encountered: