GHC Trac Home
GHC Git Repos
Report a bug
Mailing Lists & IRC
The GHC Team
GHC Status Info
Tickets I Created
Patches for review
New Feature Req
side by side
lines around each change
Show the changes in full context
White space changes
Oct 17, 2009 10:57:48 AM (
= Before You Go Any Further =
17 October 2009
Regretfully, the instructions provided below contain a serious flaw that will make your life miserable. There is, however, a satisfactory and simple workaround! The problem concerns building GHC 6.10.4 as well as GHC 6.10.1 from source on Windows. It is likely that the problem is one that dates back to the beginning and effects all versions of GHC up to the present which begs the question, How is it possible that there is a current official Windows binary package for GHC? The choice of host as opposed to build on the configure command line provides a clue. Furthermore, if you go to the web pages for the various hackage GHC packages that are available, for example go to [http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hs-dotnet].
hs-dotnet is a Windows specific package, yet under the "Distributions" row it says "Arch: 0.4.0". The 0.4.0 is a hyperlink. There is no mention of Windows. It is a hyperlink to the package page for [http://www.archlinux.org/ Arch Linux]. Ok, there are non-Windows dotnet ports, I knew that, but bare with me. The wikipedia.org page for Arch Linux is [http://en.wikipedia.org/wiki/Arch_Linux]. They write, "The design approach of the development team focuses on simplicity, elegance, code correctness and minimalism." Interestingly enough, Haskell is often described as elegant. It is what has brought me here.
I also came across something else that was interesting. Go to [http://www.mingw.org/wiki/LinuxCrossMinGW]. There is a Linux to Windows cross compiler. What does this mean to you and I? In the event that the Windows approach fails you, there has got to be a way. Try OS virtualization, dual-booting your computer, or perhaps better yet pop in a Linux Live CD and attempt to build GHC that way using the MinGW Linux to Windows cross compiler. A USB drive is useful if you pursue the Live CD approach since whatever changes you make to the Linux operating system such as installation of packages will be lost once you restart the computer. If I had known about how GHC could be built by means of the MinGW cross compiler on the front end it would have saved me a few hours. It is time consuming carrying out experimental trials. There is a defect in ghci that effects me that I believe I managed to track down and fix, but I only just been able to build GHC from source.
Now to the symptoms. If you do not apply this fix, all sorts of things will go wrong. I even managed to fix every blessed one of them and was able to successfully build GHC from source, but upon retracing my steps I learned that only one fix was actually needed. Everything else fell into place. The problem is partially described in [http://hackage.haskell.org/trac/GHC/ticket/3201]. It is marked Severity: normal. It is also marked fixed. This is also true for the bug I suspect that I managed to fix. It too was marked fixed in the bug database, but I think I understand why. Apparently, there is a difference with how things are handled on Windows and Linux that many of the developers tend not to appreciate since they are coming from a Linux background.
Getting to back to what I was talking about. I would characterize the problem as severe until you understand how to work around it. I made a tools folder as is suggested below and made that folder the first folder in the path so whatever I place there will take precedence. The Bourne shell script (sh) must not have a file extension. Window programs will frequently add a file extension even if that was your not intention. It is likely that you will need to remove its file extension explicitly. It is likely that the file must be saved using the Unix newline convention (LF instead of CR LF). I saved the file with the following content with a trailing blank line (this is sometimes important):
c:/msys/1.0/bin/xargs.exe -s 16383 $@
# 16383 is 2^14 - 1
to my tools folder. A value of 2 to the power of 15 - 1 was originally described, but gave mixed results so I chose 2 to the power of 14 - 1 to keep the value to one that can be represented in a whole number of bits. The problem is not xargs. It apparently resides in ar which is a [http://www.gnu.org/software/binutils/ GNU Binutils]. The path to ar is hard coded, however. There is no --with-ar configure command line option that I could find to override this behavior. The version of ar that is used is located under the "C:\ghc\ghc-6.10.4\bin" folder and not "C:\MinGW\bin" which took me by surprise.
= Setting up a Windows system for building GHC =