/home/bjpop/woo/lib/buddha-0.5/libbuddha_p.a(Partial.o): In function `s1jZ_fast1': Partial.o(.text+0xa44): undefined reference to `GHCziPrim_zdwZ2H_entry'

1) libbuddha_p.a is a library built from a number of modules. Each of these modules is compiled with: -O -cpp -prof -fglasgow-exts -package lang -package-name buddha

2) The problem occurs when I try to use an unboxed tuple in one of the modules:

newtype Comp a = C (CompState -> (# a, CompState #))

If I remove the unboxing, the linking problem disappears

3) removing the -prof flag doesn't seem to fix anything

4) compiling without -O fixes the problem

And some more information about the problem: 5) If I compile everything with -auto-all then the linking problem disappears. 6) If I swtich back from an unboxed tuple to a normal tuple and only recompile the module that contains that type (not every module in the program). Then I get this message: Compiling ParseLib_Buddha ( ParseLib_Buddha.hs, ParseLib_Buddha.o ) ghc-5.04.2: panic! (the `impossible' happened, GHC version 5.04.2): Missing alternative GHCziPrim.Z2H{-84-} (DataziTuple.Z2T{-74-}, [result1{-r3Au-}, newState{-r3At-}], next{-r3Av-} result1{-r3Au-} newState{-r3At-}) 7) I only export the type Comp, not its constructor. There looks to be an interaction between profiling, optimisation and the unboxed tuple. The problem may very well be with me, but I'm not sure how to find out. You may wonder why I'm compiling things with -prof. This is for my declarative debugger (buddha). I'm abusing the -prof option to get the string names of constructors in the heap representation of values. I know it is a hack, but for the moment it works well enough. Cheers, Bernie. ----- End of forwarded message from Bernard James POPE -----