November 2008 - Glasgow-haskell-users

GHC on powerpc (OS X): segmentation fault
by Chris Kuklewicz 16 Nov '08

16 Nov '08

I am having trouble compiling GHC using mac ports on powerpc OS X (10.5.5) (using XCode 3.1). I have also opened a ticket at http://trac.macports.org/ticket/17184 which has the full build log attached. The build starts with > nice port -c upgrade ghc > ---> Staging gmp into destroot > ---> Packaging tgz archive for gmp 4.2.4_0 > ---> Deactivating gmp 4.2.3_0 > ---> Installing gmp 4.2.4_0 > ---> Activating gmp 4.2.4_0 > ---> Cleaning gmp > ---> Fetching ghc > ---> Attempting to fetch ghc-6.10.1-src.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.10.1-src-extralibs.tar.bz2 from http://haskell.org/ghc/dist/stable/dist/ > ---> Attempting to fetch ghc-6.8.2-darwin-ppc-leopard-bootstrap.tar.bz2 from http://haskell.org/ghc/dist/6.8.2/ > ---> Verifying checksum(s) for ghc > ---> Extracting ghc > ---> Applying patches to ghc > ---> Configuring ghc > ---> Building ghc with target all > Error: Target org.macports.build returned: shell command "cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1 && env DYLD_FALLBACK_LIBRARY_PATH=/opt/local/lib make" returned error 2 > Command output: /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c parallel/GranSim.c -o parallel/GranSim.o Eventually the build fails with > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -optc-O -optc-I/opt/local/include -optc-Wall -optc-W -optc-Wstrict-prototypes -optc-Wmissing-prototypes -optc-Wmissing-declarations -optc-Winline -optc-Waggregate-return -optc-I../includes -optc-I. -optc-Iparallel -optc-Ism -optc-DCOMPILING_RTS -optc-fomit-frame-pointer -optc-I/opt/local/include -optc-I../gmp/gmpbuild -optc-I../libffi/build/include -optc-fno-strict-aliasing -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c sm/Sweep.c -o sm/Sweep.o > /private/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_lang_ghc/work/ghc-6.10.1/ghc/stage1-inplace/ghc -H32m -O -I/opt/local/include -L/opt/local/lib -optc-O2 -I../includes -I. -Iparallel -Ism -DCOMPILING_RTS -package-name rts -static -I/opt/local/include -I../gmp/gmpbuild -I../libffi/build/include -I. -dcmm-lint -c Apply.cmm -o Apply.o > make[1]: *** [Apply.o] Segmentation fault > make: *** [stage1] Error 2 Does anyone have a clue how to proceed?

5 9

"A lazy (~) pattern cannot bind existential type variables"?
by Conal Elliott 16 Nov '08

16 Nov '08

What is the reasoning behind the ghc restriction that "A lazy (~) pattern cannot bind existential type variables"? This error came up for me in the following code: -- | Add a continuation. data WithCont h b c = forall a. WC (h b a) (a -> c) instance Functor (WithCont h b) where fmap g ~(WC f k) = WC f (fmap g k) The error message: A lazy (~) pattern cannot bind existential type variables `a' is a rigid type variable bound by the constructor `WC' at Data/Zip/FoldL.hs:66:11 In the pattern: ~(WC f k) I also tried this variation: instance Functor (WithCont h b) where fmap g wc = WC f (fmap g k) where WC f k = wc and got this message: My brain just exploded. I can't handle pattern bindings for existentially-quantified constructors. Instead, use a case-expression, or do-notation, to unpack the constructor. In the binding group for WC f k In a pattern binding: WC f k = wc I can work around these limitations by using a lambda: instance Functor (WithCont h b) where fmap g = \ (WC f k) -> WC f (fmap g k) which I believe is equivalent. Please correct me if I'm wrong here. For infix definitions like (<*>), however, this work-around is less pleasant. For instance, (<*>) = \ (WC hf hk) (WC xf xk) -> WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) instead of the prettier but forbidden ~(WC hf hk) <*> ~(WC xf xk) = WC (hf `zip` xf) (\ (a,a') -> (hk a) (xk a')) If you're curious what these definitions are about, see http://conal.net/blog/posts/enhancing-a-zip/ . Thanks, - Conal

1 0

Re: Bug in GHC6.10.1?
by José Pedro Correia 14 Nov '08

14 Nov '08

Hello I was wondering if there is a bug in GHC 6.10.1 regarding number precision. As an example, in GHCi with: > 3.0 * 0.2 I get: 0.6000000000000001 Although: > 2.0 * 0.2 0.4 I have GHC 6.10.1 on Mac OS X 10.5. Is this a known bug or should I report it? Best regards Zé Pedro

4 3

libedit.so.0
by James Swaine 14 Nov '08

14 Nov '08

I can't seem to get the latest source bundle to build (running on Red Hat). I run the configure script, then make on the source tree root, and ghc gives an error to the effect of 'could not load shared object file or library libedit.so.0'. I don't have root permissions on this machine so I can't install editline on this machine, but I downloaded the source, built in my local directory, then tried: -Setting the LD_LIBRARY_PATH environment variable to include the directory path to the libedit.so.0 library I just built. -Hand editing the makefile in ghc's 'libraries' directory to add an -L[librarydir] flag to the ghc invocation that was failing. Neither of these things worked - is there an easy way to tell the configure script that it needs to probe additional directories for these shared libraries? Thanks all! -James Swaine

3 7

Re: Notes on building 6.10.1
by Duncan Coutts 13 Nov '08

13 Nov '08

On Wed, 2008-11-12 at 12:39 -0500, Gregory Wright wrote: > Should cabal produce and error or a warning if hsc2hs is not found in > the same directory as the compiler? I suggest an error by default, > but not if --with-hsc2hs is given explicitly. I don't think so. In principle hsc2hs is not tied to ghc, it just happens to be shipped with it. The versions do not need to match up (much). It's in the same category as other pre-processors like c2hs. For the ghc build system, either it really does need an external hsc2hs in which case it should detect it in the top level configure script or it can use the one it ships with in which case it should be using the --with-hsc2hs flag. Duncan

1 0

Notes on building 6.10.1
by Gregory Wright 13 Nov '08

13 Nov '08

Hi, When building 6.10.1 under Macports, I noticed that hpc now requires that hsc2hs be present on the system (it does not use the hsc2hs built in place with the new ghc). Previous versions did not require hsc2hs to be present; the compiler could be bootstrapped from just the ghc compiler and ghc-pkg. The hpc library is the only one that requires the external hsc2hs. Is this new dependency intentional, or is this a build system bug? This problem escaped detection initially because cabal will use any hsc2hs on the path even if the --with-compiler flag is set. (--with-compiler forces a particular compiler and packaging program, but not hsc2hs.) This is just asking for trouble. For the moment, it's fixed in the Macports build by hacking hpc's Makefile to specify --with-hsc2hs. Should cabal produce and error or a warning if hsc2hs is not found in the same directory as the compiler? I suggest an error by default, but not if --with- hsc2hs is given explicitly. Best Wishes, Greg

2 2

Newbish building question
by J. Garrett Morris 13 Nov '08

13 Nov '08

Hello, I've been attempting to add some minor instrumentation to my pet copy of GHC 6.10.1. In particular, I'd like to add some code to extendInstEnv in compiler/types/InstEnv.lhs. First, I tried importing Debug.Trace into the InstEnv module, and changing the extendInstEnv function to trace "foobar". This built file, although was not tremendously useful. Next, I tried the following modification: extendInstEnv :: InstEnv -> Instance -> InstEnv extendInstEnv inst_env ins_item@(Instance { is_cls = cls_nm, is_tcs = mb_tcs }) = trace (showSDocDebug (ppr ins_item)) (addToUFM_C add inst_env cls_nm (ClsIE [ins_item] ins_tyvar)) where add (ClsIE cur_insts cur_tyvar) _ = ClsIE (ins_item : cur_insts) (ins_tyvar || cur_tyvar) ins_tyvar = not (any isJust mb_tcs) This produced the following error message: home/garrett/code/ghc-6.10.1/ghc/stage1-inplace/ghc -package-name base-4.0.0.0-hide-all-packages -no-user-package-conf -split-objs -i -idist/build -i. -idist/build/autogen -Idist/build/autogen -Idist/build -Iinclude -optP-include -optPdist/build/autogen/cabal_macros.h -#include "HsBase.h" -odir dist/build -hidir dist/build -stubdir dist/build -package ghc-prim-0.1.0.0 -package integer-0.1.0.0 -package rts-1.0 -O -package-name base -XMagicHash -XExistentialQuantification -XRank2Types -XScopedTypeVariables -XUnboxedTuples -XForeignFunctionInterface -XUnliftedFFITypes -XDeriveDataTypeable -XGeneralizedNewtypeDeriving -XFlexibleInstances -XPatternSignatures -XStandaloneDeriving -XPatternGuards -XEmptyDataDecls -XCPP -idist/build -H32m -O -O2 -Rghc-timing -XGenerics -Wall -fno-warn-deprecated-flags -c Data/Maybe.hs -o dist/build/Data/Maybe.o -ohi dist/build/Data/Maybe.hi dist/build/GHC/Base.hi Dict fun GHC.Base.$f9: Interface file inconsistency: home-package module `base:GHC.Base' is needed, but is not listed in the dependencies of the interfaces directly imported by the module being compiled Cannot continue after interface file error <<ghc: 20271680 bytes, 2 GCs, 132152/132152 avg/max bytes residency (1 samples), 31M in use, 0.01 INIT (0.02 elapsed), 0.06 MUT (0.14 elapsed), 0.03 GC (0.04 elapsed) :ghc>> I'm not sure what to do from here - showSDocDebug comes from Outputable, which was already imported by InstEnv, so it didn't seem like I should have to change anything in the build.. /g -- I am in here

3 2

Linking error during stage2
by dermiste 13 Nov '08

13 Nov '08

Hi, I've successfully built GHC-6.10.1 from 6.6.1 on OpenBSD 4.4, and would like now to generate a hc-file-bundle to build it without pre-existing GHC. I followed the instructions in [1], but I'm stuck with this error : [....] gmake[2]: Leaving directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/ghc' gmake[1]: Leaving directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/compiler' gmake -C utils with-stage-2 gmake[1]: Entering directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils' gmake -C installPackage with-stage-2 gmake[2]: Entering directory `/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/installPackage' /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/bootstrapping.conf configure --distpref dist-install \ --prefix=/NONEXISTENT --bindir=/NONEXISTENT --libdir=/NONEXISTENT --libexecdir=/NONEXISTENT --datadir=/NONEXISTENT --docdir=/NONEXISTENT --haddockdir=/NONEXISTENT --htmldir=/NONEXISTENT \ --with-compiler=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/ghc/stage2-inplace/ghc --with-hc-pkg=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/ghc-pkg/install-inplace/bin/ghc-pkg --package-db /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/stage3.package.conf \ --libsubdir='$pkgid' --with-gcc=gcc --with-ld=/usr/bin/ld --hsc2hs-option=-I/usr/local/include --configure-option='--with-gmp-includes=/usr/local/include' --configure-option='--with-gmp-libraries=/usr/local/lib' --configure-option=--with-cc=gcc --with-hsc2hs=/usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/utils/hsc2hs/install-inplace/bin/hsc2hs \ --constraint="Cabal == 1.6.0.1" Configuring installPackage-1.0... /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/cabal-bin /usr/local/bin/ghc /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/bootstrapping.conf build --distpref dist-install --ghc-option=-H32m --ghc-option=-O --ghc-option=-fvia-C --ghc-option=-Rghc-timing --ghc-option=-keep-hc-file --ghc-option=-Wall Preprocessing executables for installPackage-1.0... Building installPackage-1.0... Linking dist-install/build/installPackage/installPackage ... /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0xac): In function `unixzm2zi3zi1zi0_SystemziPosixziSemaphore_zdwa_info': : undefined reference to `sem_trywait' {... five more like that ...} /usr/ports/lang/ghc/w-ghc-6.10.1-ghc_boot/ghc-6.10.1/libraries/unix/dist/build/libHSunix-2.3.1.0.a(Semaphore.o)(.text+0x17a4): In function `s29I_info': : undefined reference to `sem_unlink' collect2: ld returned 1 exit status <<ghc: 36084348 bytes, 5 GCs, 3492304/5176252 avg/max bytes residency (3 samples), 33M in use, 0.01 INIT (0.00 elapsed), 0.12 MUT (5.36 elapsed), 0.07 GC (0.21 elapsed) :ghc>> Obviously, the linker skips entirely /usr/lib/libpthread.a, as all the symbols defined in <semaphore.h> are into it. But its behaviour is slightly inconsistent, as I had no problem building the stage2 commenting SplitObjs in mk/build.mk some more data : I'm compiling this with the aforementioned GHC-6.10.1 bootstrapped from GHC-6.6.1. Clues anyone ? [1] http://hackage.haskell.org/trac/ghc/wiki/Building/Porting#PortingGHCtoanewp… -- Vincent Gross "So, the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well." -- Jerome Simeon & Phil Wadler

3 2

how is Linux GHC formed?
by Jason Dusek 12 Nov '08

12 Nov '08

How was the Linux binary for GHC created? I am looking at ways to compile Haskell binaries for Linux that work across distros. So far, I have been using `-static -optl-static` but today there was a weird hiccup with IO -- the Gentoo built binary worked fine on Gentoo but caught SIGPIPE intermittently on Ubuntu -- and so it's back to the drawing board. The GHC linux binary seems to work on all the Linii without discrimination, so I'd like to know what the procedure is for producing it, and what I can take away from that to put in my Cabal file. -- _jsn

3 3

impredicative type checking
by Jeff Polakow 12 Nov '08

12 Nov '08

Hello, I filed the following bug report: This produces a type error: foo :: forall b. (b -> String, Int) foo = (const "hi", 0) bar :: (forall b. b -> String, Int) bar = foo But the types are equivalent. The ticket was closed with a comment that the types are not equivalent. However, I don't see how they are not equivalent (in the presence of impredicative polymorphism) since I can write derivations for both forall b. (b -> String /\ Int) |- (forall b. b -> String) /\ Int and (forall b. b -> String) /\ Int |- forall b. (b -> String /\ Int) in intuitionistic logic. The counter example given on the bug tracker is: foo :: forall b. (b -> String, Int) foo = undefined x :: (String, String) x = case foo of (f, _) -> (f 'a', f True) which fails to type check where the other type signature would allow it to check. However, with impredicative polymorphism, this should type check. Perhaps it is too much to ask the inference engine to infer the type of f above. However, in the original code sample, there is no type inference necessary; it is just necessary to check if the two types unify, which they should given the standard interpretation of forall. Am I missing something here? -Jeff --- This e-mail may contain confidential and/or privileged information. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden.

4 4