GHC 5.00.2 Mini-FAQ

This page lists known problems for the 5.00.2 release, with workarounds.
  • The interactive system complains about missing symbols like CC_LIST when loading previously compiled .o files.

    This probably means the .o files in question were compiled for profiling (with -prof). Workaround: recompile them without profiling. We really ought to detect this situation and give a proper error message.

  • Not really a bug, but ... if the interactive system complains about missing symbols in a library, and you know those symbols should be supplied by a shared object (.so) file, remember that you can specify names of .so's on the ghci command line. These extra libraries are then also searched by the runtime linker. You can also use the -L and -l flags on the ghci command line, and they work in the usual way.

  • Linking a program causes the following error on Linux: 
      /usr/bin/ld: cannot open -lgmp: No such file or directory
    The problem is that your system doesn't have the GMP library installed. If this is a RedHat distribution, install the RedHat-supplied gmp-devel package, and the gmp package if you don't already have it. There have been reports that installing the RedHat packages also works for SuSE (SuSE don't supply a shared gmp library).

  • The -funbox-strict-fields flag sometimes gives wrong code.

    Workaround: don't use it. Use of the usual -O optimisation bundle is still safe, though, since it doesn't include -funbox-strict-fields. This will be fixed properly in 5.02.

  • When I try to start ghci (probably one I compiled myself) it says 
       ghc-5.00.2: not built for interactive use
    To get ghci, you need to build GHC 5.00.2 with itself; the above message appears if you build it with 4.08.X, for example. It'll still work fine for batch-mode compilation, though.

  • When I use a foreign function that takes or returns a float, it gives the wrong answer, or crashes.

    You should use -#include.

  • My program that uses a really large heap crashes on Windows.

    For utterly horrible reasons, programs that use more than 128Mb of heap won't work when compiled dynamically on Windows (they should be fine statically compiled).

  • GHC doesn't like filenames containing +.

    Indeed not. You could change + to p or plus.

  • My programs crashes on startup under Windows.

    Use cygcheck to make sure it's not loading any DLLs it shouldn't be. My favourite is having a copy of gmp.dll in my Windows system directory. You'll need to remove such DLLs, or copy the ones you need into the same directory as the program, to make sure they're used in preference to DLLs in the system directories.

  • I get screenfuls of errors from GCC when I compile my Haskell module.

    If you're using the C back-end (which happens by default with -O, and is mandatory for -prof), then you can't use top-bit-set characters in identifiers, because they are not valid in C. GHC should be mangling them, and will in the next release. In the meantime, use the native backend (-fasm). Désolé.

  • When I open a FIFO (named pipe) and try to read from it, I get EOF immediately.

    This is a consequence of the fact that GHC opens the FIFO in non-blocking mode. The behaviour varies from OS to OS: on Linux and Solaris you can wait for a writer by doing an explicit threadWaitRead on the file descriptor (gotten from Posix.handleToFd) before the first read, but this doesn't work on FreeBSD. A workaround for all systems is to open the FIFO for writing yourself, before (or at the same time as) opening it for reading.

  • When I foreign import a function that returns char or short, I get garbage back.

    This is a known bug, GHC currently doesn't mask out the more significant bits of the result. It doesn't manifest with gcc 2.95, but apparently shows up with g++ and gcc 3.0.