Friday, January 2, 2009

Fighting dependencies

Looks like the stage1 build has succeeded, but stage2 died trying to link against libreadline.so.4. I only had a lib for .so.5 .. sigh.

After soft linking libreadline.so.5 to libreadline.so.4, had to copy across a new version of the GHC readline lib because it had gotten into a weird state.

Alright. It looks like I've got a sane build environment on mavericks. My build of GHC 6.8.3 made it through stage1 and the libs. I ran part of the testsuite and it seems fine.

Installed the binary distro of GHC 6.8.3 on sparky. Trying to get the build working. I'm still learning about where all the progs and libs are supposed to be on solaris. For some reason all the goodies in /usr/sfw, /opt/csw and /usr/css aren't in the default $PATH.

While compiling fresh copies of GHC 6.8.3 and GHC 6.10 on mavericks, some modules seem to take a very long time.. this is from top:
3273 benl       1   0    0  392M  142M cpu     47:25 79.63% cc1
^^^^^

47 minutes and still going? Smells like trouble.

Yah, my GHC 6.10.1 build died:
Constructor GHC.IOBase.IORef:
Can't find interface-file declaration for type constructor or class GHC.STRef.STRef
Probable cause: bug in .hi-boot file, or inconsistent .hi file
Use -ddump-if-trace to get an idea of which file caused the error
Cannot continue after interface file error


I'm guessing this was a build race. I just ran make again and it seems ok now.

That other module is still compiling:
3273 benl       1   0    0  393M  259M cpu     94:15 90.09% cc1
^^^^^

I looked into it and the .hc file was from the Happy generated parser, and is 2 MB big. I suppose cc doesn't like compiling 2MB source files..

Looks like the GHC 6.8.3 binary distro I installed on sparky didn't work. When I try and build something with it it dies with:
checking for path to top of build tree... In file included from /home/benl/software/ghc-6.8.3/lib/ghc-6.8.3/include/Stg.h:183,

from /tmp/ghc5891_0/ghc5891_0.hc:3:0:

/home/benl/software/ghc-6.8.3/lib/ghc-6.8.3/include/Regs.h:28:17:
gmp.h: No such file or directory
In file included from /home/benl/software/ghc-6.8.3/lib/ghc-6.8.3/include/Stg.h:183,

from /tmp/ghc5891_0/ghc5891_0.hc:3:0:

/home/benl/software/ghc-6.8.3/lib/ghc-6.8.3/include/Regs.h:121:0:
error: syntax error before "MP_INT"
....


I don't know if it's possible to change the pre-built GHC so it searches another include path, so I just added a softlink from /opt/csw/includes/gmp.h to ghc-6.8.3/lib/ghc-6.8.3/include/gmp.h. It's a hack, but it seems to have fixed it.

Now my other build on mavericks has caught up with the first one:
  3273 benl       1   0    0  394M  325M cpu    161:25 95.89% cc1
15563 benl 1 0 0 371M 271M cpu 35:19 95.10% cc1


Configuring GHC 6.8.3 on sparky is causing problems, not sure why:

bash-3.00$ sh boot
Booting .
configure.ac:887: warning: AC_CACHE_VAL(fp_gcc_version, ...): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:1988: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2001: AC_CACHE_CHECK is expanded from...
aclocal.m4:548: FP_HAVE_GCC is expanded from...
configure.ac:887: the top level
configure.ac:887: warning: AC_CACHE_VAL(fp_gcc_version, ...): suspicious cache-id, must contain _cv_ to be cached
autoconf/general.m4:1988: AC_CACHE_VAL is expanded from...
autoconf/general.m4:2001: AC_CACHE_CHECK is expanded from...


The configure script on sparky must not have detected alex properly. There's a happy error later on as well.

== make boot - --no-print-directory -r;
in /home/benl/devel/ghc/ghc-6.8.3-build/utils/genprimopcode
------------------------------------------------------------------------
g Lexer.x
make[2]: g: Command not found
make[2]: [Lexer.hs] Error 127 (ignored)


When trying to unpack happy
bash-3.00$ gzip -dc happy-1.17.tar.gz |tar xf -
tar: ././@LongLink: typeflag 'L' not recognized, converting to regular file


Sigh. Built GNU tar, installed happy and alex on both mavericks and sparky.

Submitted a bug report about the 2MB intermediate C file for Parser.hs. There's no way a single source file is supposed to take 2 hrs to compile. Looking at the generated parser code, the parser has 545 states, and there are 109589 lines in the generated source file. This gives about 201 lines of C code per state.

At a guess, the trouble is that every parser state is represented by its own, named function. That's reasonable approach from a FP point of view, but it could cause some serious code blowout if not handled well.

Killed an attempted compile of the parser module with GHC flag -O0, after 121 mins running. Tried to compile it instead with -O2. ... didn't make any difference. The .hc is still 2MB.

Another compile of GHC 6.8.3 managed to finish Parser.hs after several hours (not sure how many) and is stuck on libraries/template-haskell/Language/Haskell/TH/Syntax.hs. The intermediate C code is 4MB this time.

I'll leave it overnight and see how far it gets..

No comments:

Post a Comment