Hi, all, is it expected that a snapshot version (I'm using 2009.06.05) should be able to build the released version 6.10.3? This weekend I tried the "porting to an unsupported machine" procedure with the aforementioned snapshot version; that worked, after some fussing, and I seem to have a working ghc install, including several libraries and cabal. But I tried building the Haskell Platform, and it warns (rightly, as it turns out) about this being an unsupported version of ghc. So I'd like to get onto the regular release train, as it were, and transfer myself to ghc 6.10.3. But that fails to build, after a while. Specifically, it goes until it's trying to compile the stage1 version of ghc/Main.hs, and then it complains that it can't find the file "../includes/ghcautoconf.h". Now, that file does exist; but it looks like it's being referenced from HsVersions.h, which lives in the lib/ tree of the installed snapshot compiler, and relative to the location of that file, there is indeed no such path. Is that a bug? If I create the includes directory where HsVersions.h appears to be seeking it, and add in ghcautoconf.h from where it got created during the setup of ghc 6.10.3, the build proceeds (a little) further, but it still dies. thanks... Uwe PS I suppose I should describe in a little bit of detail what I did for the porting, might be useful for someone else trying this. It was a rather vanilla port, x86_64-unknown-linux to same; my target machine is my workstation at work, where I don't have root, and I do have permission from IT to install this stuff, but no support... so they won't install rpms for me, or anything like that. It's also a slightly old and somewhat customized version of some RedHat corporate release, so recent plain-vanilla tarballs didn't work... hence the need to port. So: first problem was that my target machine identified itself as x86_64-unknown-linux-gnu; note the 4-part identifier, rather than the 3-part that's more usual. That confused the configure scripts... I had to hack up configure.ac to force it to see itself as x86_64-unknown-linux. First problem solved... After that, the back-and-forth of the various derived files was tedious but straightforward, and stuff built well. The second problem was that the command listed on the ghc porting page, "for c in libraries/*/configure; ...", is specific to bash or sh, and my workstation runs tcsh. No problem, I knew what to do, but it might be an issue for someone who doesn't know. The third issue was the sed syntax on the same page: the version of sed that I was using didn't like the space between the "-i" and the ".bak". I don't know if that's a variation from one version of sed to another, or a typo on the page, or??? Again no big deal, the error message from sed was informative enough for me to figure out what to do. The fourth issue was that the "make all_ghc_stage2" command failed: the linker complained that it couldn't find the hs_main symbol. I found that in RtsMain.o, and manually added that object file to the appropriate (?) library; then it worked. I'm not actually sure that I got the actually-most-correct library, but... it didn't seem to break anything. After that, it went through ok. I checked that that stage2 compiler could indeed build a working executable from haskell sources, that was ok, and then I rebuilt that snapshot from scratch using that compiler. That worked fine, and after that the various libraries needed to get cabal up and running were straightforward.