- Glasgow-haskell-users

Compiling 32-bit GHC on a 64-bit Mac
by Johan Tibell 06 Jun '11

06 Jun '11

Hi, I need to reproduce a bug that only appears on 32-bit machines. I don't own such a machine but I was hoping I could compile a 32-bit GHC on my Mac and debug using that. What changes do I need to make (e.g. to build/mk) to build a 32-bit GHC? Cheers, Johan

3 3

ANNOUNCE: GHC 7.0.4 Release Candidate 1
by Ian Lynagh 04 Jun '11

04 Jun '11

We are pleased to announce the first release candidate for GHC 7.0.4: http://www.haskell.org/ghc/dist/7.0.4-rc1/ This includes the source tarball, installers for OS X and Windows, and bindists for amd64/Linux, i386/Linux, amd64/FreeBSD and i386/FreeBSD. Please test as much as possible; bugs are much cheaper if we find them before the release! Release notes: * A floating point regression in 7.0.3 affecting x86 has been fixed (#5149). * The GHCi linker now handles partially stripped object files (#5004). This fixes loading the ghc package in ghci when it's been stripped, which is often the case in Linux distribution packages. * A runtime system bug with large heaps has been fixed (#5086). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug when heap profiling has been fixed (#5127). * A runtime system bug, which caused incorrect results and segfaults when using FFI callbacks, has been fixed. * A runtime system bug, which occasionally caused parallel programs to <<loop>> when using -feager-blackholing, has been fixed (#5226). * Incorrect directory permissions when installing have been fixed (#4982). * Some improvements have been made to the new Cabal testsuite support. * Cabal is now 1.10.2.0 (was 1.10.1.0). Thanks Ian, on behalf of the GHC team

2 1

Re: ld weirdness in unstable
by Joachim Breitner 02 Jun '11

02 Jun '11

Dear Joey, strange observation... for more eyes looking at it, I’m replying with full-quote to the GHC mailing list as well. (That list is subscriber-only, AFAIK, in case you want to follow up there). Am Mittwoch, den 01.06.2011, 19:09 -0400 schrieb Joey Hess: > I've noticed this problem with ld process size recently while doing > edit-compile-debug development cycles with git-annex on unstable. > > Normally, ld runs in seconds, using maybe 170 mb or memory according to > top, but I suspect real memory is somewhat less. > > Sometimes I get into a state where every link takes minutes, and > apparently uses somewhat more memory and typically triggers the OOM > killer. > > Whenever this happens, I have to `make clean; make` and then it seems > back to normal. > > The build is being driven by ghc --make. And the best way to trigger it > seems to be to make changes to types, or other changes to core > modules that cause a fan-out effect where ghc needs to rebuild lots of > other modules. Greetings, Joachim -- Joachim "nomeata" Breitner Debian Developer nomeata(a)debian.org | ICQ# 74513189 | GPG-Keyid: 4743206C JID: nomeata(a)joachim-breitner.de | http://people.debian.org/~nomeata

1 0

Addr# field in ForeignPtr
by Roman Leshchinskiy 01 Jun '11

01 Jun '11

Hi all, GHC defines ForeignPtr as: data ForeignPtr a = ForeignPtr Addr# ForeignPtrContents -- we cache the Addr# in the ForeignPtr object, but attach -- the finalizer to the IORef (or the MutableByteArray# in -- the case of a MallocPtr). The aim of the representation -- is to make withForeignPtr efficient; in fact, withForeignPtr -- should be just as efficient as unpacking a Ptr, and multiple -- withForeignPtrs can share an unpacked ForeignPtr. Note -- that touchForeignPtr only has to touch the ForeignPtrContents -- object, because that ensures that whatever the finalizer is -- attached to is kept alive. Is it ok to modify the Addr# field? Or do the libraries assume that it always points to the start of the block described by ForeignPtrContents? Changing the Addr# field would be quite useful for pointing to the middle of a memory block. For instance, Storable vectors are currently defined as: data Vector a = Vector {-# UNPACK #-} !(Ptr a) {-# UNPACK #-} !Int {-# UNPACK #-} !(ForeignPtr a) If I could use the Addr# field of the ForeignPtr, I could get rid of the Ptr. Alternatively, I could define my own version of ForeignPtr if only ForeignPtrContents was exported (abstractedly would be enough). Roman

2 1

testsuite, failures galore
by Daniel Fischer 01 Jun '11

01 Jun '11

So my last testsuite run (validate --slow) with a new HEAD produced 651 unexpected failures :( Okay, the thing is that I forgot to add EXTRA_HC_OPTS=-optl-lz, see http://hackage.haskell.org/trac/ghc/ticket/3756 So, unless I miscounted, 611 of those were in way threaded1 due to: > Linking arrowrun001 ... > /usr/lib/gcc/i586-suse-linux/4.5/../../../libbfd.a(compress.o): In > function `bfd_uncompress_section_contents': > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:96:0: > undefined reference to `inflateInit_' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:106:0: > undefined reference to `inflateReset' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:103:0: > undefined reference to `inflate' > > /usr/src/packages/BUILD/binutils-2.20.0/build- dir3/bfd/../../bfd/compress.c:108:0: > undefined reference to `inflateEnd' > > collect2: ld gab 1 als Ende-Status zurück > > *** unexpected failure for arrowrun001(threaded1) The ticket has low priority, but if anybody has an idea how to check whether libbfd depends on libz in the configure script, I'd appreciate it. Of the remaining 40 unexpected failures, 14 were due to the removal of datatype contexts (tcrun006 and tcrun029), 7 (tcrun007) were due to a parse error because -XGenerics does nothing anymore (so ghc couldn't parse "{|"), 3 due to a missing Show instance in dph. The remaining may or may not be serious, looking at them now.

3 10

Manipulating DynFlags importPaths
by Joshua Ball 31 May '11

31 May '11

Hi, What's the right way to alter the importPaths in the DynFlags? The following program freezes: -- requires ghc package import GHC import DynFlags ( defaultDynFlags ) main = defaultErrorHandler defaultDynFlags $ do runGhc (Just "/home/jball/lib/ghc-7.0.3") $ do dflags <- getSessionDynFlags let dflags = dflags { importPaths = ["/alt/path"] } setSessionDynFlags dflags I am using ghc 7.0.3, as you might have guessed. Josh "Ua" Ball

1 1

shared libraries on OS X
by John Lato 28 May '11

28 May '11

Hello, I recently tried to build ghc on OS X Snow Leopard as 64-bit with shared library support. I had to self-compile gmp and modify mk/build.mk (I later saw that Edward Amsden blogged about the same experience, http://blog.edwardamsden.com/2011/04/howto-install-ghc-703-on-os-x-64-bit.h…) and it seemed to work, but executables don't run. For example, with this small program: > import qualified Data.Vector.Unboxed as V > main = let vec = V.replicate 10 (1 :: Int) in print $ V.sum vec I get this result: Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo dyld: Library not loaded: /private/var/folders/aJ/aJF0t1uBF7WDCz1PZV0A0U+++TI/-Tmp-/vector-0.7.0.176669/vector-0.7.0.1/dist/build/libHSvector-0.7.0.1-ghc7.0.3.dylib Referenced from: /Users/johnlato/./foo Reason: image not found Trace/BPT trap It seems that dyld is looking into build folders for the libraries. If I set DYLD_LIBRARY_PATH before compiling it appears to work: Mac-1:~ johnlato$ export DYLD_LIBRARY_PATH=~/.cabal/lib/vector-0.7.0.1/ghc-7.0.3/:~/.cabal/lib/primitive-0.3.1/ghc-7.0.3/ Mac-1:~ johnlato$ ghc -O -dynamic foo.hs [1 of 1] Compiling Main ( foo.hs, foo.o ) Linking foo ... Mac-1:~ johnlato$ ./foo 10 This seems to be required for any libraries I've installed via cabal-install --user, which quickly becomes onerous. Could anyone give me some advice on how to make this work properly (e.g. without manually setting DYLD_LIBRARY_PATH)? Thanks, John

1 0

Dynamic linking in Windows GHC 7.0.3
by Hussain Sobhy 27 May '11

27 May '11

When using dynamic linking on windows, shared libraries seem to be stored in same folders where the packages where installed i.e each library in a different folder. And these folders aren't visible to the system (by the PATH variable). Is it possible to specify the folder to which the libraries (libHSrts-ghc8.03.dll etc.) will be stored ? for example C:\Windows\System32 Because currently when I try to run any executable which is dynamically linked it complains about missing dlls. Thanks

1 0

Exported modules in the GHC API
by David Waern 27 May '11

27 May '11

Hi, When encountering an IEModuleContents ModuleName export item, I'd like a simple way to get its original Module (with the original module name and package ID). It seems a bit complicated to have to go through the import items to figure this out. My question is: is there a simpler way, and if not, do you agree that the API should provide a simpler way? Thanks, David

2 4

Completely reproducible Haskell builds
by Greg Steuck 27 May '11

27 May '11

I am trying to get ghc-7.0.3 build procedure down to a byte-identical rebuild on Linux-amd64. I solved one source of variability: ar embedding timestamps into .a files (HOWTO at the end) Now I am looking to eliminate variations in ELF64 executables. To make things easy, I am going to demonstrate with unlit binary. I start at a point where make leaves off. % cp utils/unlit/dist/build/tmp/unlit{,.1} % "/usr/bin/ghc" -o utils/unlit/dist/build/tmp/unlit -O -H64m -package-conf libraries/bootstrapping.conf -i -iutils/unlit/. -iutils/unlit/dist/build -iutils/unlit/dist/build/autogen -Iutils/unlit/dist/build -Iutils/unlit/dist/build/autogen -no-user-package-conf -rtsopts -odir utils/unlit/dist/build -hidir utils/unlit/dist/build -stubdir utils/unlit/dist/build -hisuf hi -osuf o -hcsuf hc -no-auto-link-packages -no-hs-main utils/unlit/dist/build/unlit.o % sha1sum utils/unlit/dist/build/tmp/unlit{,.1} 6f679d9dd9a9ea84a68be99369c9f1dc72ba41f0 utils/unlit/dist/build/tmp/unlit beed059e09c9429c3b74ea613d5be30c6c17ac3c utils/unlit/dist/build/tmp/unlit.1 % ls -l utils/unlit/dist/build/tmp/unlit{,.1} -rwxr-x--- 1 gnezdo eng 15112 May 25 21:53 utils/unlit/dist/build/tmp/unlit -rwxr-x--- 1 gnezdo eng 15112 May 25 21:53 utils/unlit/dist/build/tmp/unlit.1 % for i in utils/unlit/dist/build/tmp/unlit{,.1}; do readelf -a $i > $i.elf; done % diff utils/unlit/dist/build/tmp/unlit{,.1}.elf 250c250 < 27: 0000000000000000 0 FILE LOCAL DEFAULT ABS ghc27965_0.c --- > 27: 0000000000000000 0 FILE LOCAL DEFAULT ABS ghc20499_0.c Looks like there is a temporary file name baked into the ELF file. Indeed, running with -v reveals: *** C Compiler: /usr/bin/gcc -c /tmp/ghc28016_0/ghc28016_0.c -o /tmp/ghc28016_0/ghc28016_0.o -I/usr/lib/ghc-7.0.3/include -fno-stack-protector *** Linker: /usr/bin/gcc -v -o utils/unlit/dist/build/tmp/unlit -fno-stack-protector utils/unlit/dist/build/unlit.o /tmp/ghc28016_0/ghc28016_0.o Digging a bit into the sources reveals mkExtraCObj in DriverPipeline.hs which calls newTempName. The best option for dealing with this seems to be using gcc ability to accept input from a pipe. I know I could make this work on a Posix system. Yet I suspect getting it to work on Windows would be overly onerous. Next best idea is to make GHC use repeatable temporary .c & .o file names for each invocation. There is already a unique temporary directory where all the the temporary files are created. This suggests I do not need to worry about adversarial races. So GHC just need to avoid racing with itself. I see a couple of options: 1) newTempName should create a new subdirectory for each call and the return a fixed name inside of this (so /tmp/ghc28016_0/ghc28016_0.c above would become /tmp/ghc28016_0/0/dummy.c) 2) mkExtraCObj could compute some hash function of its xs argument (C program text) and then create a file named, e.g. /tmp/ghc28016_0/38eb8d8eb0abe9c828ba60983e2a97f7a069ec41.c Which of these two looks better? Other ideas? Would people be open to accepting a patch along these lines if I were to write one? The steps to make ar not include the timestamps were 1) Add "AR_OPTS = qD" to build.mk. This takes care of most .a files. 2) Set AR_FLAGS=qD in the evironment and dummy out ranlib (create a no-op script called ranlib on your PATH prior to real ranlib). This takes care of libffi build. Thanks Greg -- nest.cx is Gmail hosted, use PGP for anything private. Key: http://tinyurl.com/ho8qg Fingerprint: 5E2B 2D0E 1E03 2046 BEC3 4D50 0B15 42BD 8DF5 A1B0

3 3