Building on Windows
Hi, I just successfully built GHC on Windows. Last time I tried (5 years ago) it took days. This time, it took hours, plus a bit of waiting for a Windows specific breakage to be fixed. I made a log of what happened, what confused me, what wasn't clear etc - hopefully these provide suggestions for improving the wiki (if my thoughts are actually correct). The worst aspect is that the Windows wiki page has 6 sets of instructions, with no obvious way to pick the right one - everything else was pretty minor. Thanks, Neil My first step was to Google build ghc on windows, which took me to https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows The instructions are current for GHC 7.6 - so they are not current. Other documentation for Windows includes: - here are 5 alternate links, any of which may be better/worse than this one. I have no way to tell. As a piece of documentation, giving the uninformed user 6 options with no sensible way to make a decision is awful. Simon PJ had said MSYS2 works well, so I clicked that one. Even though it appears to be the wrong one according to the wiki. Is it the correct one? If so, replace the Windows page with it. If not, perhaps indicate which one is. It should get you running in ~5 minutes, modulo download speeds. - nice! It's a long way from being true, since you also need to include extraction times and build times (which on my machine far outweight download times). There were also enough hiccups that it took me about an hour of clicking/typing, excluding the Windows specific bug I ran into. If I have 64bit OS, should I pick 64bit Windows? Or only if I want to develop 64bit Windows, which isn't the default? Fortunately my machine is old enough to be 32 bits so I didn't have the difficult question. It's far easier to edit the PATH file manually with $ cygpath -w ~, which returns C:\msys32\home\Neil, than to echo stuff to it. In particular, if you echo anything wrong, you need to edit it anyway. Do not install python, python2 or gcc! - it's not entirely clear how to achieve that. It installed gcc-libs, is that a problem? I'd have liked a better check step, e.g. run gcc --version, ghc --version and exactly what I should expect, what indicates a problem etc. e.g what should i be on the lookout for to say Python doesn't build. I followed the step to upgrade my system, but it failed: :: Starting full system upgrade... :: Replace msys2-base with msys/filesystem? [Y/n] (55/55) checking for file conflicts[##] 100% error: failed to commit transaction (conflicting files) bash-completion: /etc/profile.d/bash_completion.sh exists in filesystem coreutils: /etc/DIR_COLORS exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/java/cacerts exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/openssl/ca-bundle.trust.crt exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/email-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/objsign-ca-bundle.pem exists in filesystem ca-certificates: /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem exists in filesystem filesystem: /etc/profile.d/lang.sh exists in filesystem filesystem: /etc/profile.d/tzset.sh exists in filesystem filesystem: /etc/skel/.inputrc exists in filesystem filesystem: /mingw32_shell.bat exists in filesystem filesystem: /mingw64_shell.bat exists in filesystem filesystem: /msys2_shell.bat exists in filesystem grep: /usr/bin/egrep exists in filesystem grep: /usr/bin/fgrep exists in filesystem rebase: /autorebase.bat exists in filesystem Errors occurred, no packages were upgraded. I just ignored that, and continued, and that seemed to go OK... /ghc-7.6.3/ didn't work, I needed to go /c/ghc/ghc-7.6.3/ for the paths. Perhaps make it clear which are absolute paths, and which you have to edit. Perhaps you were hoping I'd symlink the GHC path? Any reason for the commands in the final list of commands? isn't one per line cleaner? It also lets you retry the right bit when something fails. checking for version of happy... 1.18.4 configure: error: Happy version 1.19.4 or later is required to compile GHC. Nice - this was a useful check that made it easy to fix and continue. $ make -j3 + test -f mk/config.mk.old + cp -p mk/config.mk mk/config.mk.old touch -r mk/config.mk.old mk/config.mk + test -f mk/project.mk.old + cp -p mk/project.mk mk/project.mk.old touch -r mk/project.mk.old mk/project.mk 2 [main] make 6024 child_info_fork::abort: C:\msys32\bin\msys-unistring-2.dll: Loaded to different address: parent(0x25) != child(0x7C) make: fork: Resource temporarily unavailable This error repeated. On a hunch I ran autorebase.bat from msys32, and restarted my shell, then it worked - I have no idea which fixed it. inplace/bin/ghc-stage1.exe -hisuf hi -osuf o -hcsuf hc -static -H32m -O-this-package-key haske_9y30zKcKDr9BxdhpktYrNk -hide-all-packages -i -ilibraries/haskeline/.
RE: Cleaning up rather silly static arguments
If I were to try to find a way to get rid of these things, should I try hacking
on the static argument transformation, or would it fit better in the
simplifier, or somewhere else?
Yes, this is just what the static argument transformation is for. I’ve added
your example to https://ghc.haskell.org/trac/ghc/ticket/9374
Simon
From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of David Feuer
Sent: 16 September 2014 03:03
To: ghc-devs
Subject: Cleaning up rather silly static arguments
Aside from anything having to do with the foldrW/buildW stuff, I decided to try
a little experiment using fusing scanl and reverse (implementations at
http://lpaste.net/2416758997739634688 )
When I define
scanr f b = reverse . scanl (flip f) b . reverse
I get this:
scanr1
scanr1 = \ @ a_akP _ eta_Xb - eta_Xb
scanr
scanr =
\ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -
letrec {
go_amb
go_amb =
\ ds_amc eta1_Xa eta2_B2 eta3_Xc -
case ds_amc of _ {
[] - eta1_Xa eta2_B2 eta3_Xc;
: y_amh ys_ami -
go_amb
ys_ami
(\ x_an9 eta4_Xj -
let {
b'_ana
b'_ana = f_ah8 y_amh x_an9 } in
eta1_Xa b'_ana (: b'_ana eta4_Xj))
eta2_B2
eta3_Xc
}; } in
go_amb eta_B1 (scanr1) b_ah9 (: b_ah9 ([]))
go_amb takes four arguments, two of which, eta2_B2 and eta3_Xc, are static.
What makes this seem particularly silly is that we already have all the
structure we need to get rid of them—all that remains is to actually delete
them and replace them with the values they take:
scanr1
scanr1 = \ @ a_akP _ eta_Xb - eta_Xb
scanr
scanr =
\ @ a_akP @ a1_akQ f_ah8 b_ah9 eta_B1 -
let {
listend
listend = : b_ah9 ([])} in
letrec {
go_amb
go_amb =
\ ds_amc eta1_Xa -
case ds_amc of _ {
[] - eta1_Xa b_ah9 listend;
: y_amh ys_ami -
go_amb
ys_ami
(\ x_an9 eta4_Xj -
let {
b'_ana
b'_ana = f_ah8 y_amh x_an9 } in
eta1_Xa b'_ana (: b'_ana eta4_Xj))
}; } in
go_amb eta_B1 (scanr1)
Now I certainly wouldn't claim this is particularly *good* code, but it seems
significantly more reasonable than before.
If I were to try to find a way to get rid of these things, should I try hacking
on the static argument transformation, or would it fit better in the
simplifier, or somewhere else?
David
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs
Re: cminusminus.org does not have a link to the spec
On Mon, 15 Sep 2014 12:05:27 + Simon Peyton Jones simo...@microsoft.com wrote: My planned change is for GHC's .cmm files syntax/codegen. The idea came out after having stumbled upon a rare ia64 bug in GHC's C codegen: http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc074cac721 The fundamental bug here is the following: Suppose we have two bits of rts: one .c file and one .cmm file // rts.c defines and exports a function and a variable void some_rts_fun (void); int some_rts_var; // rts.cmm uses rts.c's function and variable import some_rts_fun; /* this forces C codegen to emit function-like 'StgFunPtr some_rts_fun ();' prototype, it's fine */ import some_rts_var; /* also forces C codegen to emit function-like 'StgFunPtr some_rts_var ();' prototype, it's broken */ // ... W whatever = some_rts_var; /* will pick address not to a real variable, but to a so called function stub, a separate structure pointing to real 'some_rts_var' */ I plan to tweak syntax to teach Cmm to distinct between imported C global variables/constants, imported Cmm info tables(closures), maybe other cases. I thought of adding haskell-like syntax for imports: foreign ccall import some_rts_fun; foreign cdata import some_rts_var; or maybe import some_rts_fun; import some_rts_fun as some_rts_fun; This sort of bugs can be easily spotted by whole-program C compiler. gcc can do it with -flto option. I basically added to the mk/build.mk: SRC_CC_OPTS += -flto SRC_LD_OPTS += -flto -fuse-linker-plugin SRC_HC_OPTS += -optc-flto SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin and started with './configure --enable-unregisterised' It immediately shown some of current offenders: error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as function error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as function I hope this fuzzy explanation makes some sense. Thanks! Sergei C-- was originally envisaged as a target language for a variety of compilers. But in fact LLVM, which was developed at a similar time, won that race and has built a far larger ecosystem. That's fine with us -- it's great how successful LLVM has been -- but it means that C-- is now used essentially only in GHC. I'm not sure where the original C-- documents now are; Norman can you say? (I do know that the cminusminus.org has lapsed.) The GHC variant of C-- is defined mainly by the Cmm data type in GHC's source code. It does have a concrete syntax, because some bits of GHC's runtime system are written in Cmm. But I fear that this concrete language is not well documented. (Simon Marlow may know more here.) Because GHC's Cmm is part of GHC, we are free to change it. Would you like to say more about the change you want to make, and why you want to make it? Is this relating directly to GHC or to some other project? Simon | -Original Message- | From: Sergei Trofimovich [mailto:sly...@gmail.com] | Sent: 14 September 2014 17:16 | To: Simon Peyton Jones | Subject: cminusminus.org does not have a link to the spec | | Hello Simon! | | I had a plan to tweak a bit import statement | syntax of Cmm in GHC. | | Namely, to distinct between | import some_c_function; | import some_c_global_variable; | | To try it I first attempted to find latest c-- spec | (to find some design sketches if available) at | | http://www.cminusminus.org/c-downloads/ | | But seems the links (and images?) have gone away | as well as rsync server described at: | | http://www.cminusminus.org/the-c-rsync-server/ | | Maybe you could forward it to site admins so they would | tweak links or point me to working copy. | | Apologies for bothering you on such minor | | Thank you! | | -- | | Sergei -- Sergei signature.asc Description: PGP signature ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
RE: cminusminus.org does not have a link to the spec
Thanks. This is beyond my competence, and I'm totally submerged anyway. I suggest you make a Trac ticket about it anyway. Simon Marlow will probably have an opinion. Simon | -Original Message- | From: Sergei Trofimovich [mailto:sly...@gmail.com] | Sent: 16 September 2014 19:03 | To: Simon Peyton Jones | Cc: Norman Ramsey; ghc-devs; Simon Marlow | Subject: Re: cminusminus.org does not have a link to the spec | | On Mon, 15 Sep 2014 12:05:27 + | Simon Peyton Jones simo...@microsoft.com wrote: | | My planned change is for GHC's .cmm files syntax/codegen. | The idea came out after having stumbled upon a rare ia64 | bug in GHC's C codegen: | | | http://git.haskell.org/ghc.git/commitdiff/e18525fae273f4c1ad8d6cbe1dea4fc | 074cac721 | | The fundamental bug here is the following: | Suppose we have two bits of rts: one .c file and one .cmm file | | // rts.c defines and exports a function and a variable | void some_rts_fun (void); | int some_rts_var; | | // rts.cmm uses rts.c's function and variable | import some_rts_fun; /* this forces C codegen to emit function-like |'StgFunPtr some_rts_fun ();' | prototype, it's fine */ | | import some_rts_var; /* also forces C codegen to emit function-like |'StgFunPtr some_rts_var ();' | prototype, it's broken */ | // ... | W whatever = some_rts_var; /* will pick address not to a real | variable, but to a | so called | function stub, a separate structure | pointing to real | 'some_rts_var' */ | | I plan to tweak syntax to teach Cmm to distinct between | imported C global variables/constants, imported Cmm info | tables(closures), maybe other cases. | | I thought of adding haskell-like syntax for imports: | foreign ccall import some_rts_fun; | foreign cdata import some_rts_var; | | or maybe | import some_rts_fun; | import some_rts_fun as some_rts_fun; | | This sort of bugs can be easily spotted by whole-program C compiler. | gcc can do it with -flto option. I basically added to the mk/build.mk: | SRC_CC_OPTS += -flto | SRC_LD_OPTS += -flto -fuse-linker-plugin | SRC_HC_OPTS += -optc-flto | SRC_HC_OPTS += -optl-flto -optl-fuse-linker-plugin | and started with './configure --enable-unregisterised' | | It immediately shown some of current offenders: | error: variable 'ghczmprim_GHCziTypes_False_closure' redeclared as | function | error: variable 'ghczmprim_GHCziTypes_True_closure' redeclared as | function | | I hope this fuzzy explanation makes some sense. | | Thanks! | | Sergei | | C-- was originally envisaged as a target language for a variety of | compilers. But in fact LLVM, which was developed at a similar time, | won that race and has built a far larger ecosystem. That's fine with | us -- it's great how successful LLVM has been -- but it means that C-- is | now used essentially only in GHC. | | I'm not sure where the original C-- documents now are; Norman can you | say? (I do know that the cminusminus.org has lapsed.) | | The GHC variant of C-- is defined mainly by the Cmm data type in GHC's | source code. It does have a concrete syntax, because some bits of GHC's | runtime system are written in Cmm. But I fear that this concrete language | is not well documented. (Simon Marlow may know more here.) | | Because GHC's Cmm is part of GHC, we are free to change it. Would you | like to say more about the change you want to make, and why you want to | make it? Is this relating directly to GHC or to some other project? | | Simon | | | | -Original Message- | | From: Sergei Trofimovich [mailto:sly...@gmail.com] | | Sent: 14 September 2014 17:16 | | To: Simon Peyton Jones | | Subject: cminusminus.org does not have a link to the spec | | | | Hello Simon! | | | | I had a plan to tweak a bit import statement | | syntax of Cmm in GHC. | | | | Namely, to distinct between | | import some_c_function; | | import some_c_global_variable; | | | | To try it I first attempted to find latest c-- spec | | (to find some design sketches if available) at | | | | http://www.cminusminus.org/c-downloads/ | | | | But seems the links (and images?) have gone away | | as well as rsync server described at: | | | | http://www.cminusminus.org/the-c-rsync-server/ | | | | Maybe you could forward it to site admins so they would | | tweak links or point me to working copy. | | | | Apologies for bothering you on such minor | | | | Thank you! | | | | -- | | | | Sergei | | | -- | | Sergei ___ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs
