February 2013 - ghc-devs

iconv_open failure --- WAS: Re: scheduleWaitThread looping
by Gabor Greif 23 Feb '13

23 Feb '13

On 2/23/13, Stephen Paul Weber <singpolyma(a)singpolyma.net> wrote: > Somebody claiming to be Gabor Greif wrote: >>I have finally have a cross compiler building, but encounter a new >>problem with a simple "Hello World" program not working. >> >>HeapProfTimer endlessly and nothing useful happens. Any idea what >>could be wrong, or how I could tackle debugging this problem. The >>native build of the same program with same compiler version (HEAD) >>works well. > > This may be unrelated, but I've had a similar issue that I haven't finished > > debugging yet. > > Is the LANG environment variable set? Trying running with LANG="" Hi Stephen! This did not help. But you pointed me to the right direction :-) I observed that in each loop 'iconv_open' gets called, but returns a failure (-1) Breakpoint 1, 0x0fdac770 in iconv_open () from /lib/tls/libc.so.6 (gdb) p (char*)$r3 $1 = 0x3010401c "ANSI_X3.4-1968" (gdb) p (char*)$r4 $2 = 0x30104008 "UTF-32BE" (gdb) call iconv_open("ANSI_X3.4-1968","UTF-32BE") $3 = -1 (gdb) call iconv_open("ASCII","ASCII") $4 = 272079520 (gdb) call iconv_open("ASCII","UTF-32BE") $5 = -1 (gdb) call iconv_open("ASCII","UTF-32") $6 = -1 (gdb) call iconv_open("ASCII","UTF-8") $7 = 272088200 (gdb) call iconv_open("ANSI_X3.4-1968","UTF-8") $8 = 272120976 As you see my manual attempts to get a converter towards UTF-8 worked. The main problem is that upon failure, an error with a message is thrown, which restarts the scheduler loop again, but cannot display any message because in order to do that it needs to open iconv again... A veritable catch-22. So all keeps looping and nothing happens. Here is the relevant code from base/GHC/IO/Encoding/Iconv.hs: newIConv from to rec fn = -- Assume charset names are ASCII withCAString from $ \ from_str -> withCAString to $ \ to_str -> do iconvt <- throwErrnoIfMinus1 "mkTextEncoding" $ hs_iconv_open to_str from_str let iclose = throwErrnoIfMinus1_ "Iconv.close" $ hs_iconv_close iconvt return BufferCodec{ encode = fn iconvt, recover = rec, close = iclose, -- iconv doesn't supply a way to save/restore the state getState = return (), setState = const $ return () } What is disturbing me, that this simple hello-world program used to work a year ago, with no iconv-related problems at all, and I am wondering what has changed since 7.5 and how to salvage the situation now? I am thankful for any suggestions, cheers, Gabor > > -- > Stephen Paul Weber, @singpolyma > See <http://singpolyma.net> for how I prefer to be contacted > edition right joseph >

1 0

[PATCH] (base) Fix documentation
by shelarcy 23 Feb '13

23 Feb '13

Hello, Data.String's document decribes wrong option name. I made patch to fix that. Best Regards, -- shelarcy <shelarcy hotmail.co.jp> http://page.freett.com/shelarcy/

1 0

one other (relatively minor) issue building on Windows
by Daniel Pratt 22 Feb '13

22 Feb '13

I encountered one other (relatively minor) issue building on Windows: In my recently installed MinGW environment, there was no "usr/local" folder until I created it. For this reason, the "make install" process silently failed to copy the binaries to their intended location.

1 0

Re: [commit: ghc] master: Always quote arguments to removeFiles (fixes Windows install). (1a3247f)
by Gabor Greif 22 Feb '13

22 Feb '13

On 2/22/13, Geoffrey Mainland <gmainlan(a)microsoft.com> wrote: > Repository : ssh://darcs.haskell.org//srv/darcs/ghc > > On branch : master > > http://hackage.haskell.org/trac/ghc/changeset/1a3247f6a5d98c15139e8650c88a6… > >>--------------------------------------------------------------- > > commit 1a3247f6a5d98c15139e8650c88a61284a786731 > Author: Geoffrey Mainland <gmainlan(a)microsoft.com> > Date: Fri Feb 22 15:26:55 2013 +0000 > > Always quote arguments to removeFiles (fixes Windows install). > > Thanks to Daniel Pratt <colorblinddad(a)gmail.com> for pointing out the > failure > and fix. > ... > install_ghc_post: install_bins > - $(call removeFiles,$(DESTDIR)$(bindir)/ghc.exe) > + $(call removeFiles,"$(DESTDIR)$(bindir)/ghc.exe") This should be $(call removeFiles,"$(DESTDIR)$(bindir)/$(CrossCompilePrefix)ghc.exe") Cheers, Gabor > "$(MV)" -f $(DESTDIR)$(bindir)/ghc-stage$(INSTALL_GHC_STAGE).exe > $(DESTDIR)$(bindir)/$(CrossCompilePrefix)ghc.exe > endif > > http://www.haskell.org/mailman/listinfo/ghc-commits >

1 0

make install fails on Windows (8?) -- redux
by Daniel Pratt 22 Feb '13

22 Feb '13

My first attempt to build GHC (on Windows 8) from sources went pretty well until I got to the "make install" step. Some research revealed that at least one other person got the same error I did<http://www.haskell.org/pipermail/cvs-ghc/2012-November/078353.html>building on Windows. That other person "fixed" the problem by deleting the offending lines from the build scripts. I looked around a bit and noticed that pretty much every other place else that removeFiles was referenced, the path was quoted. I added quotes to the paths on the two offending lines and subsequently the "make install" process completed without errors. I'm happy to log a bug, submit a patch, etc., but since this would be my first time doing that, I thought I should run it by you folks first. The wiki suggests adding a test case for a bug, but since this is a build error, I suppose that wouldn't make sense?

2 1

libraries/binary does not compile with ghc-7.7
by Gabor Greif 20 Feb '13

20 Feb '13

Hi all, when bootstrapping with GHC-7.7 I get HC [stage 0] libraries/binary/dist-boot/build/Data/Binary/Get.o libraries/binary/src/Data/Binary/Get.hs:101:1: Warning: The import of `GHC.Int' is redundant except perhaps to import instances from `GHC.Int' To import instances alone, use: import GHC.Int() libraries/binary/src/Data/Binary/Get.hs:371:15: Warning: In the use of `unsafeInterleaveST' (imported from Control.Monad.ST): Deprecated: "Please import from Control.Monad.ST.Unsafe instead; This will be removed in the next release" libraries/binary/src/Data/Binary/Get.hs:383:44: Warning: In the use of `unsafeInterleaveST' (imported from Control.Monad.ST): Deprecated: "Please import from Control.Monad.ST.Unsafe instead; This will be removed in the next release" HC [stage 0] libraries/binary/dist-boot/build/Data/Binary/Builder/Base.o libraries/binary/src/Data/Binary/Builder/Base.hs:180:22: Ambiguous occurrence `unsafePerformIO' It could refer to either `Foreign.unsafePerformIO', imported from `Foreign' at libraries/binary/src/Data/Binary/Builder/Base.hs:69:1-14 or `System.IO.Unsafe.unsafePerformIO', imported from `System.IO.Unsafe' at libraries/binary/src/Data/Binary/Builder/Base.hs:71:1-23 (and originally defined in `GHC.IO') make[1]: *** [libraries/binary/dist-boot/build/Data/Binary/Builder/Base.o] Error 1 I have two commits to fix this: $ git show ded894cd6abb209406e2ce16361acbb7111774d0 commit ded894cd6abb209406e2ce16361acbb7111774d0 Author: Gabor Greif <ggreif(a)gmail.com> Date: Thu Oct 25 12:59:53 2012 +0200 fix import warnings diff --git a/src/Data/Binary/Get.hs b/src/Data/Binary/Get.hs index 7134217..eaba669 100644 --- a/src/Data/Binary/Get.hs +++ b/src/Data/Binary/Get.hs @@ -92,13 +92,13 @@ import Control.Applicative (Applicative(..)) import Foreign -- used by splitAtST -import Control.Monad.ST +import Control.Monad.ST (ST, runST) +import Control.Monad.ST.Unsafe (unsafeInterleaveST) import Data.STRef #if defined(__GLASGOW_HASKELL__) && !defined(__HADDOCK__) import GHC.Base import GHC.Word -import GHC.Int #endif -- | The parse state $ git show 9c8b00ab88b6b8b996e0725d242df9a225d4236e commit 9c8b00ab88b6b8b996e0725d242df9a225d4236e Author: Gabor Greif <ggreif(a)gmail.com> Date: Thu Oct 25 13:39:28 2012 +0200 do not import unsafePerformIO from Foreign (eliminating warning) diff --git a/src/Data/Binary/Builder/Base.hs b/src/Data/Binary/Builder/Base.hs index 8124f65..31b5115 100644 --- a/src/Data/Binary/Builder/Base.hs +++ b/src/Data/Binary/Builder/Base.hs @@ -67,6 +67,7 @@ import qualified Data.ByteString.Lazy as L import Data.Monoid import Data.Word import Foreign +import System.IO.Unsafe (unsafePerformIO) #ifdef BYTESTRING_IN_BASE import Data.ByteString.Base (inlinePerformIO) @@ -174,7 +175,7 @@ data Buffer = Buffer {-# UNPACK #-} !(ForeignPtr Word8) -- the lazy 'L.ByteString' is demanded. -- toLazyByteString :: Builder -> L.ByteString -toLazyByteString m = unsafePerformIO $ do +toLazyByteString m = System.IO.Unsafe.unsafePerformIO $ do buf <- newBuffer defaultSize runBuilder (m `append` flush) (const (return L.Empty)) buf {-# INLINE toLazyByteString #-} Okay to push to master? Cheers, Gabor

2 3

Re: No newline at end of file
by Kazu Yamamoto 20 Feb '13

20 Feb '13

Edward, > I went ahead and fixed it; Thanks. > why is FreeBSD choking on lack of trailing newlines though? I'm not sure. But I saw "error" and probably "-Werror" in "validate" stopped building. --Kazu

1 0

No newline at end of file
by Kazu Yamamoto 20 Feb '13

20 Feb '13

Hi, The current libraries/dph-lifted-copy/Data/Array/Parallel/PArray/ScalarInstances.hs does not have a new line at end of file. This is one of reasons why "validate" does not work on FreeBSD at this moment. --Kazu

1 0

libraries/unix: ghc-cabal: No buildable component found
by Karel Gardas 19 Feb '13

19 Feb '13

Hello, I'm trying to build GHC cross-compiler to RTEMS OS, but I'm stuck on getting this error message from ghc-cabal while configuring libraries/unix: ghc-cabal: No buildable component found gmake[1]: *** [libraries/unix/dist-install/package-data.mk] Error 1 I'm not able to find out under which condition(s) cabal signals "no buildable component found" on this particular library. Any idea? Thanks a lot! Karel

2 1

Dreaded "... has stopped working" with LLVM back end on Win64
by Geoffrey Mainland 18 Feb '13

18 Feb '13

I'm using the 7.6.2 Win64 port to try to compile HEAD with the quick-llvm BuildFlavour (I'm using LLVM 3.1). This entails setting -optlc-mtriple=x86_64-w64-mingw32 since the LLVM back-end doesn't output the right triple when producing .ll files. Unfortunately I get the dreaded "ghc-cabal.exe has stopped working" pop-up dialog as soon as ghc-cabal.exe is invoked. Interestingly, ghc-cabal.exe behaves as expected when invoked with no command line arguments. I have no idea where to start with this one. Any hints? Has anyone ever used the LLVM back end on Win64 (I'm guessing not). Thanks, Geoff

1 0