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.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
