RE: Strange Building problem...
I am presently trying to build GHC on an i386 Linux box running debian/sid. (Yea, I know there's a .deb - in fact, I have it installed - but I need to be able to compile my own.)
I've run configure and make, and stage 1 went quite well although there were a few syntax problems (usually due to #ifdef's in the source .hs files apparantly overrunning or underrunning; easily fixed by just deleting the problematic #ifdef chunks for other architectures).
Stage 2, however, seems to have a problem: make runs "make -C ghc/compiler stage=2", which then runs "../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.0 -H16m -O -i
-DGHCI -package haskell-src -package unix -package readline -cpp -fglasgow-exts -Rghc-timing -I. -IcodeGen -IativeGen -Iparser -recomp -Rghc-timingn -H16m `#include "hschooks.h"` -no-link-chk " This then produces: stage2/utils/Util.o(.text+0xb8): In funtion "r4c8_entry": undefined reference to "GHCziBase_True_Closure"
... and roughly 40,000 errors of the same form.
"Something has gone wrong" :-) GHCziBase_True_closure is a symbol that should be coming from the base package, the GHC.Base module in particular. You could check that libraries/base/libHSbase.a looks reasonable: it should be on the order of 17Mb. Try 'nm' on it, look for some of the missing symbols. Cheers, Simon
On Wed, Jul 30, 2003 at 06:01:22PM +0100, Simon Marlow wrote:
stage2/utils/Util.o(.text+0xb8): In funtion "r4c8_entry": undefined reference to "GHCziBase_True_Closure"
... and roughly 40,000 errors of the same form.
GHCziBase_True_closure is a symbol that should be coming from the base
Note that the case of the 'C' of the missing symbol is different, and nm shows only the lower case 'c' on my (6.0.1) stage2/utils/Util.o. I don't know what that means, though. I have sometimes found it worth checking that ghc-inplace can compile simple hello-world programs and that they run OK. Ian
On Wed, 30 Jul 2003 18:01:22 +0100, you wrote:
GHCziBase_True_closure is a symbol that should be coming from the base package, the GHC.Base module in particular. You could check that libraries/base/libHSbase.a looks reasonable: it should be on the order of 17Mb. Try 'nm' on it, look for some of the missing symbols.
Hi, Thanks very much for your reply. I looked and the libraries/base/libHSbase.a file is there, is the correct size, and does contain the missing references. The only problem is that the compiler doesn't seem to be seeing it. I tried looking in the makefile to see if I could insert a path directive somewhere, but I'm not very experienced with UNIX makefiles so I couldn't find where I ought to put such a thing. What is odd is that ghc-inplace is invoked by the make process several times before this big one (which appears to be the start of stage 2?) and works fine...
participants (3)
-
Ian Lynagh -
Mark Green -
Simon Marlow