HEAD: Problem Linking genapply in 6.5.20060510

I'm continuing in my quest to produce a clean build of GHC for Mac intel. I'm using registerised .hc files built on 386 linux. I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names? The build log was: gcc -x c GenApply.hc -o GenApply.raw_s -S -O -fno-builtin -fno-defer- pop -fomit-frame-pointer -mdynamic-no-pic - DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/readline/include -I. `echo | sed 's/^$/- DSTOLEN_X86_REGS=4/'` ../../driver/mangler/ghc-asm GenApply.raw_s GenApply.s as -o GenApply.o GenApply.s gcc -o genapply -fno-builtin -fno-defer-pop -fomit-frame-pointer - mdynamic-no-pic -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ libraries/readline/include -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/rts -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/rts/ gmp -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base -L/Users/ rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base/cbits -L/Users/rfh/ ghc-6.5/mac/ghc-6.5.20060510/libraries/haskell98 -L/Users/rfh/ghc-6.5/ mac/ghc-6.5.20060510/libraries/parsec -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/Cabal -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/template-haskell -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/readline -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/unix -L/Users/rfh/ghc-6.5/mac/ ghc-6.5.20060510/libraries/unix/cbits -u "_GHCziBase_Izh_static_info" -u "_GHCziBase_Czh_static_info" -u "_GHCziFloat_Fzh_static_info" -u "_GHCziFloat_Dzh_static_info" -u "_GHCziPtr_Ptr_static_info" -u "_GHCziWord_Wzh_static_info" -u "_GHCziInt_I8zh_static_info" -u "_GHCziInt_I16zh_static_info" -u "_GHCziInt_I32zh_static_info" -u "_GHCziInt_I64zh_static_info" -u "_GHCziWord_W8zh_static_info" -u "_GHCziWord_W16zh_static_info" -u "_GHCziWord_W32zh_static_info" -u "_GHCziWord_W64zh_static_info" -u "_GHCziStable_StablePtr_static_info" -u "_GHCziBase_Izh_con_info" -u "_GHCziBase_Czh_con_info" -u "_GHCziFloat_Fzh_con_info" -u "_GHCziFloat_Dzh_con_info" -u "_GHCziPtr_Ptr_con_info" -u "_GHCziStable_StablePtr_con_info" -u "_GHCziBase_False_closure" -u "_GHCziBase_True_closure" -u "_GHCziPack_unpackCString_closure" -u "_GHCziIOBase_stackOverflow_closure" -u "_GHCziIOBase_heapOverflow_closure" -u "_GHCziIOBase_NonTermination_closure" -u "_GHCziIOBase_BlockedOnDeadMVar_closure" -u "_GHCziIOBase_Deadlock_closure" -u "_GHCziWeak_runFinalizzerBatch_closure" -u "___stginit_Prelude" GenApply.o -lHSreadline -lHStemplate-haskell -lHSunix - lHSunix_cbits -lHSCabal -lHShaskell98 -lHSbase -lHSbase_cbits - lHSparsec -lHSrts -lgmp -lm -lreadline -lncurses -ldl /usr/bin/ld: Undefined symbols: _GHCziList_lvl22_closure _GHCziList_zdwlen_info collect2: ld returned 1 exit status make[1]: *** [genapply] Error 1 Reilly Hayes

On 5/13/06, Reilly Hayes
I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log
On actual problem, I have no idea except the simple..maybe .hi files were inconsistent with object files.
below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names?
I might be wrong on any of this, but I'm giving it a shot as it might take over weekend before Simons or anyone else answers. It's called zencoding, found in http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs _ on start is just some typical c-name thingy. Otherwise those symbols are from GHC.List module. _info and _closure mean different use of that name that comes before them (lvl22 and $wlen). I think compiler/cmm/CLabel.hs might help on that, or rather modules that use it. I am not sure how to track name generators for lvl22 and $. HTH, --Esa

thanks, As this occurred while bootstrapping from .hc files, there are no .hi files built yet. -reilly hayes On May 12, 2006, at 7:57 PM, Esa Ilari Vuokko wrote:
On 5/13/06, Reilly Hayes
wrote: Hi I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log
On actual problem, I have no idea except the simple..maybe .hi files were inconsistent with object files.
below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names?
I might be wrong on any of this, but I'm giving it a shot as it might take over weekend before Simons or anyone else answers.
It's called zencoding, found in http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs _ on start is just some typical c-name thingy. Otherwise those symbols are from GHC.List module. _info and _closure mean different use of that name that comes before them (lvl22 and $wlen). I think compiler/cmm/CLabel.hs might help on that, or rather modules that use it. I am not sure how to track name generators for lvl22 and $.
HTH, --Esa
Reilly Hayes

The HC files you are bootstrapping from are probably inconsistent; that is, the HC files for the libraries were generated more recently than the HC files for genapply. Try going back to the tree you generated these HC files from, and compiling a fresh set for genapply. Cheers, Simon Reilly Hayes wrote:
thanks,
As this occurred while bootstrapping from .hc files, there are no .hi files built yet.
-reilly hayes
On May 12, 2006, at 7:57 PM, Esa Ilari Vuokko wrote:
On 5/13/06, Reilly Hayes
wrote: Hi I suspect today's problem is pretty easy to figure out for a GHC expert, but I'm not. When I try to build utils/genapply, the link fails because the symbols _GHCziList_lvl22_closure and _GHCziList_zdwlen_info are undefined. I'll include the build log
On actual problem, I have no idea except the simple..maybe .hi files were inconsistent with object files.
below. While we're on the topic, can somebody explain the algorithm used to generate these symbol names?
I might be wrong on any of this, but I'm giving it a shot as it might take over weekend before Simons or anyone else answers.
It's called zencoding, found in http://darcs.haskell.org/ghc/compiler/utils/Encoding.hs _ on start is just some typical c-name thingy. Otherwise those symbols are from GHC.List module. _info and _closure mean different use of that name that comes before them (lvl22 and $wlen). I think compiler/cmm/CLabel.hs might help on that, or rather modules that use it. I am not sure how to track name generators for lvl22 and $.
HTH, --Esa
Reilly Hayes

This one probably means that the libraries have changed since you compiled the compiler. GHCziList_zdwlen_info means GHC.List.$wlen_info (except that we use z-encoding for the funny symbols) This labels the info table (_info) for the "worker" (the $w) for the "len" function. And indeed I changed the implementation of length in GHC.List recently. The makefile does not include dependencies from the compiler modules on the library modules. Do'make clean' in compiler/ and then make. Simon | -----Original Message----- | From: glasgow-haskell-users-bounces@haskell.org [mailto:glasgow-haskell-users- | bounces@haskell.org] On Behalf Of Reilly Hayes | Sent: 13 May 2006 03:16 | To: glasgow-haskell-users@haskell.org | Subject: HEAD: Problem Linking genapply in 6.5.20060510 | | | I'm continuing in my quest to produce a clean build of GHC for Mac | intel. I'm using registerised .hc files built on 386 linux. | | I suspect today's problem is pretty easy to figure out for a GHC | expert, but I'm not. When I try to build utils/genapply, the link | fails because the symbols _GHCziList_lvl22_closure and | _GHCziList_zdwlen_info are undefined. I'll include the build log | below. While we're on the topic, can somebody explain the algorithm | used to generate these symbol names? | | The build log was: | | gcc -x c GenApply.hc -o GenApply.raw_s -S -O -fno-builtin -fno-defer- | pop -fomit-frame-pointer -mdynamic-no-pic - | DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - | D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/readline/include -I. `echo | sed 's/^$/- | DSTOLEN_X86_REGS=4/'` | ../../driver/mangler/ghc-asm GenApply.raw_s GenApply.s | as -o GenApply.o GenApply.s | gcc -o genapply -fno-builtin -fno-defer-pop -fomit-frame-pointer - | mdynamic-no-pic -DDONT_WANT_WIN32_DLL_SUPPORT -mdynamic-no-pic - | D__GLASGOW_HASKELL__=605 -O -I/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/includes -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/base/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/unix/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/parsec/include -I/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/ | libraries/readline/include -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/rts -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/rts/ | gmp -L/Users/rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base -L/Users/ | rfh/ghc-6.5/mac/ghc-6.5.20060510/libraries/base/cbits -L/Users/rfh/ | ghc-6.5/mac/ghc-6.5.20060510/libraries/haskell98 -L/Users/rfh/ghc-6.5/ | mac/ghc-6.5.20060510/libraries/parsec -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/libraries/Cabal -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/libraries/template-haskell -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/libraries/readline -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/libraries/unix -L/Users/rfh/ghc-6.5/mac/ | ghc-6.5.20060510/libraries/unix/cbits -u "_GHCziBase_Izh_static_info" | -u "_GHCziBase_Czh_static_info" -u "_GHCziFloat_Fzh_static_info" -u | "_GHCziFloat_Dzh_static_info" -u "_GHCziPtr_Ptr_static_info" -u | "_GHCziWord_Wzh_static_info" -u "_GHCziInt_I8zh_static_info" -u | "_GHCziInt_I16zh_static_info" -u "_GHCziInt_I32zh_static_info" -u | "_GHCziInt_I64zh_static_info" -u "_GHCziWord_W8zh_static_info" -u | "_GHCziWord_W16zh_static_info" -u "_GHCziWord_W32zh_static_info" -u | "_GHCziWord_W64zh_static_info" -u | "_GHCziStable_StablePtr_static_info" -u "_GHCziBase_Izh_con_info" -u | "_GHCziBase_Czh_con_info" -u "_GHCziFloat_Fzh_con_info" -u | "_GHCziFloat_Dzh_con_info" -u "_GHCziPtr_Ptr_con_info" -u | "_GHCziStable_StablePtr_con_info" -u "_GHCziBase_False_closure" -u | "_GHCziBase_True_closure" -u "_GHCziPack_unpackCString_closure" -u | "_GHCziIOBase_stackOverflow_closure" -u | "_GHCziIOBase_heapOverflow_closure" -u | "_GHCziIOBase_NonTermination_closure" -u | "_GHCziIOBase_BlockedOnDeadMVar_closure" -u | "_GHCziIOBase_Deadlock_closure" -u | "_GHCziWeak_runFinalizzerBatch_closure" -u "___stginit_Prelude" | GenApply.o -lHSreadline -lHStemplate-haskell -lHSunix - | lHSunix_cbits -lHSCabal -lHShaskell98 -lHSbase -lHSbase_cbits - | lHSparsec -lHSrts -lgmp -lm -lreadline -lncurses -ldl | /usr/bin/ld: Undefined symbols: | _GHCziList_lvl22_closure | _GHCziList_zdwlen_info | collect2: ld returned 1 exit status | make[1]: *** [genapply] Error 1 | | | Reilly Hayes | | | | | | _______________________________________________ | Glasgow-haskell-users mailing list | Glasgow-haskell-users@haskell.org | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
participants (4)
-
Esa Ilari Vuokko
-
Reilly Hayes
-
Simon Marlow
-
Simon Peyton-Jones