- Glasgow-haskell-users

Understanding ghc-pkg dependencies when not using cabal
by Tim Cuthbertson 02 Jun '12

02 Jun '12

Hi all, I'm very interested in distributing ghc packages via zero-install [0]. I'm excited about ghc 7.4's ${pkgroot} support, since it means that many packages could now be made relocatable (as long as they don't need to know about paths to resources, etc). But I'm having some trouble understanding exactly what relationships exist between packages and when packages are needed / used. I have a lot of questions. Answering all of them would be wonderful, but even just some at least would be handy too ;) For an example, lets use ansi-terminal [1] (and assume we're building it on a unix host) ansi-terminal depends on `base` and `unix` packages. Do these need to be present in source form, or just in "compiled package" form? I'm assuming the latter. (by "compiled package", I mean the stuff that ends up in e.g ~/.cabal/lib/PACKAGENAME) When I built ansi-terminal, the package.conf I got out of `cabal register` had the following field: depends: base-4.5.0.0-6db966b4cf8c1a91188e66d354ba065e unix-2.5.1.0-c004d6a0692bba682bbf2ac7b61d8322 So presumably this is the exact version that was used for compilation. Obviously the first part is the version, but what is the second part? Is it the abi-hash of the library that was used at compile time? If I want to use ansi-terminal in a program that I'm compiling, how strict are these dependencies? Will a `unix` package of a different version and the same abi-hash be acceptable? Does it need to be strictly _newer_ than 2.5.1.0 (and still have the same abi-hash)? Or is this an exact dependency? If I distribute the `unix` library in compiled form, how likely is it that a given compiled version of `unix` will satisfy the requirement? If I have compiled two libraries that both depend on `unix`, but they ended up referencing a different abi-hash of `unix` (maybe I compiled them on a different computer, or on slightly different versions of the source), what happens when I try to compile an application that depends on these two libraries? I presume it couldn't work, even if I had registered both versions of `unix` simultaneously (is this even possible to do?). Under what circumstances will the same package source code (e.g "unix-2.5.1.0") have two different abi-hashes? From [2], it sounds like only major GHC version changes should affect it. Is the abi-hash consistent on different platforms (assuming the same major GHC version is used)? Can the output of `ghc --abi-hash` (with no arguments) be used as a "linkage" restriction? (i.e if I have the exact same source and two versions of ghc with the same abi-hash, will the compiled library necessarily end up with the same abi-hash in both cases?). If the `unix` package releases a new version that is compatible with ansi-terminal, what would I have to do to get this updated code into my application (that depends on ansi-terminal)? - install new version of `unix`, and recompile my application - as above, but also rebuilding the current version of `ansi-terminal` before I rebuild my application (despite ansi-terminal not actually changing itself) Perhaps the above question could be rephrased as "if a new version of `unix` is source-compatible with the previous, what recompilation (if any) of downstream libraries is / could be required? I know that ghc compiles applications statically by default. Given this, I'm a little confused by the lifetime of packages in ghc. Are packages (in the sense of "the stuff that is listed by `ghc-pkg list`") only required at compilation time? If I run a precompiled program that depends on another haskell package which has been compiled as a shared library, does this mean I need the ghc package to be registered, or is it sufficient to just have the compiled .so on my $LD_LIBRARY_PATH? Apologies for the large number of questions, and thanks for your time. - Tim. [0]: http://0install.net/ [1]: http://hackage.haskell.org/package/ansi-terminal-0.5.5 [2]: http://hackage.haskell.org/trac/ghc/wiki/Commentary/Packages

2 2

can't compile ghc-7.4.1: No rule to make target `libraries/process/ghc.mk'
by Tim Cuthbertson 30 May '12

30 May '12

I've rm -rf'd my ~/.cabal to ensure old stuff doesn't get in the way, installed all the dependencies (on fedora 17, bootstrapping with ghc-7.0.4), unpacked the ghc-7.4.1 tarball, and run: ./configure --prefix=`pwd`/installed && make && make install and here's the log: https://gist.github.com/20dd47cfac4c8bbe498c (sorry I missed the top, `tee` didn't work right and my scrollback buffer wasn't big enough. I think I got the important stuff though). there seems to be a lot of "*/*.hi is missing (ignoring)" messages, culminating in: Configuring hsc2hs-0.67... make[1]: *** No rule to make target `libraries/process/ghc.mk'. Stop. make: *** [all] Error 2 Any hints? Cheers, - Tim.

2 2

ghc trac not sending verification emails?
by Tim Cuthbertson 29 May '12

29 May '12

I signed up for an account on http://hackage.haskell.org/trac/ghc/ to report a couple of bugs, but can't file them until my email address is verified. I've tried two different email addresses, waited more than 24 hours, and checked my spam folder but sill don't see anything. Is email sending busted? I know that the cabal trac is migrating to github, does that affect GHC's trac as well? Cheers, - Tim.

2 2

relocatable packages: GHC_PACKAGE_PATH and package.conf
by Tim Cuthbertson 29 May '12

29 May '12

Hi all, I'm trying to build a relocatable package using cabal, and running into some difficulties. I've created / used the following script to attempt to create a relocatable package: https://github.com/gfxmonk/0compile-cabal-build/blob/2cf4a08b146333d9292f6f… When this is done I have something that looks like it should work, and has an inline package.conf. But when I run the following: ----------------------------------------------- $ export GHC_PACKAGE_PATH="/home/tim/dev/haskell/third-party/haskell-ansi-terminal/haskell-ansi-terminal-linux-x86_64/package.conf:" $ ghc-pkg check There are problems in package ansi-terminal-0.5.5: import-dirs: ${pkgroot}/lib is a relative path library-dirs: ${pkgroot}/lib is a relative path file System/Console/ANSI.hi is missing file System/Console/ANSI/Unix.hi is missing file System/Console/ANSI/Common.hi is missing cannot find libHSansi-terminal-0.5.5.a on library path The following packages are broken, either because they have a problem listed above, or because they depend on a broken package. ansi-terminal-0.5.5 ----------------------------------------------- So it looks like: - I need to set more environment variabes so that ghc can find the parts of the package (e.g libHSansi-terminal-0.5.5.a). Unfortunately, I don't know what "library path" refers to in the above message (I tried $LD_LIBRARY_PATH and $LIB_PATH to no avail). - ghc doesn't seem to support ${pkgroot} prefixes. I thought it did, but I'm new to this so I may be misunderstanding where they can be used. Can anyone suggest what I might need to fix (either in the package.conf or in my environment variables) to get this working? I've uploaded my package.conf here, apologies for the lack of formatting: https://gist.github.com/59a0d3e69751c3932579 Additionally, the paths that come out of cabal build have the compiler name and version hard coded, e.g lib/packagename/ghc-7.0.4/*. Is there any way to configure how this path is constructed to get rid of the ghd-7.0.4 part? If I need to add $DISTDIR/ansi-terminal-0.5.5/ghc-7.0.4/ to a library path, it would be much easier to declare that if it didn't depend on the version of GHC used. Assume that since I'm building a standalone package, there is no problem with collisions (packages for other versions of GHC or other compilers would have a different $PREFIX). I'd really like to get relocatable packages working, so any help or guidance would be appreciated. Cheers, - Tim.

2 2

Strange behavior in GHC-compiled code
by Mark Conway Wirt 27 May '12

27 May '12

Hi folks. I have a piece of Haskell code that's been laying around on my computer for about a year, and I recently decided to dust it off. The problem is that it used to work fine, but in the interim (in which I both upgraded OS versions/GHC versions and went from 32 bit to 64 bit) the code stopped working reliably. It tends to work OK for small data sets, but with larger data sets it exhibits one of three bad behaviors: 1) A segfault, 2) An "Error in array index" error, or 3) The following runtime error: internal error: evacuate: strange closure type 5060208 (GHC version 7.0.3 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Aborted It complies OK, although with optimization turned on it gives me a "has one call pattern, but the limit is 0" error, but my understanding is that this shouldn't really be an issue. I'd like to figure out what this issue is, but while I understand a bit about the language itself, with my knowledge of GHC and the way it works I don't really know where to begin. (The strange non-deterministic nature of the problem makes me wonder if it could be something not related to Haskell, such as a hardware or memory error. Is this possible or likely?) Any guidance/pointers would be very much appreciated. Thanks. -Mark

3 4

Potential GSoC proposal: Reduce the speed gap between 'ghc -c' and 'ghc --make'
by Mikhail Glushenkov 24 May '12

24 May '12

Hi all, [Hoping it's not too late.] During my work on parallelising 'ghc --make' [1] I encountered a stumbling block: running 'ghc --make' can be often much faster than using separate compile ('ghc -c') and link stages, which means that any parallel build tool built on top of 'ghc -c' will be significantly handicapped [2]. As far as I understand, this is mainly due to the effects of interface file caching - 'ghc --make' only needs to parse and load them once. One potential improvement (suggested by Duncan Coutts [3]) is to produce whole-package interface files and load them in using mmap(). Questions: Would implementing this optimisation be a worthwhile/realistic GSoC project? What are other potential ways to bring 'ghc -c' performance up to par with 'ghc --make'? [1] https://github.com/23Skidoo/ghc-parmake [2] https://gist.github.com/1360470 [3] http://www.reddit.com/r/haskell/comments/qwj5j/the_cabal_of_my_dreams/c41a5… -- () ascii ribbon campaign - against html e-mail /\ www.asciiribbon.org - against proprietary attachments

5 14

How to staticly build ghc?
by Magicloud Magiclouds 21 May '12

21 May '12

Hi, I am with ghc 7.4.1. For some reason I need a totally static linked compilation to my code. But it failed when linking some packages came with ghc, like unix-2.5.1.0. Trying to rebuild ghc to make all staticly, but failed to find args like this when configuring ghc. What should I do? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

1 0

ANNOUNCE: GHC 7.4.2 Release Candidate 1
by Ian Lynagh 18 May '12

18 May '12

We are pleased to announce the first release candidate for GHC 7.4.2: http://www.haskell.org/ghc/dist/7.4.2-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! Thanks Ian, on behalf of the GHC team

4 4

Re: GHC 7.2.2 Distribution.Simple.Program.Ar
by Duncan Coutts 18 May '12

18 May '12

On 18 May 2012 22:03, Joe Buehler <aspam(a)cox.net> wrote: > Duncan Coutts wrote: > >> I'm very surprised it's not working on some version of Red Hat. This >> has worked on many varieties of linux for many years. You don't have >> some non-standard ar installed do you? What version of gnu binutils? >> (ar -V) > > No, it's the RHES ar program. > > # rpm -qf /usr/bin/ar > binutils-2.14.90.0.4-42 > > A CentOS 6 box works fine, so this may be a bug in RHES 3. > > The installed binutils is the latest for RHES 3. Locally compiled > versions of binutils have the same bug, so perhaps there is a bug > elsewhere in the system. For example, I do not have the very latest C > library. As a local workaround you can of course hack your Cabal library sources and reinstall the lib. Until we work out what's going on I'm a bit reluctant to chage the upstream version since that has been tested on so many systems (Linuxes, BSDs, other unixes). Duncan

1 0

GHC 7.2.2 Distribution.Simple.Program.Ar
by Joe Buehler 18 May '12

18 May '12

I built GHC 7.2.2 on a LINUX box running RHEL 3. When compiling a package using this GHC it is trying to invoke ar thus: execve("/usr/bin/ar", ["/usr/bin/ar", "-r", "-c", "dist/build/libHSregex-base-0.93."..., "dist/build/Text/Regex/Base.o", "dist/build/Text/Regex/Base/Regex"..., "dist/build/Text/Regex/Base/Conte"..., "dist/build/Text/Regex/Base/Impl."...], [/* 45 vars */]) = 0 My version of ar does not like being invoked as "/usr/bin/ar -r -c lib.a file file file...", it complains that the .a file is missing. I believe it should be "/usr/bin/ar rc lib.a file file file...". This appears to originate in Distribution.Simple.Program.Ar. Can someone tell me what is going on here? Joe Buehler

2 1