Chapter 13. GHC FAQ

This section has the answers to questions that get asked regularly on the GHC mailing lists, in no particular order. Please let us know if you think there's a question/answer that should be added here.

How do I port GHC to platform X?

There are two distinct possibilities: either

The hardware architecture for your system is already supported by GHC, but you're running an OS that isn't supported (or perhaps has been supported in the past, but currently isn't). This is the easiest type of porting job, but it still requires some careful bootstrapping.
Your system's hardware architecture isn't supported by GHC. This will be a more difficult port (though by comparison perhaps not as difficult as porting gcc).

Both ways require you to bootrap from intermediate HC files: these are the stylised C files generated by GHC when it compiles Haskell source. Basically the idea is to take the HC files for GHC itself to the target machine and compile them with gcc to get a working GHC, and go from there.

The Building Guide has all the details on how to bootstrap GHC on a new platform.

Do I have to recompile all my code if I upgrade GHC?

Yes. There are two reasons for this:

GHC does a lot of cross-module optimisation, so compiled code will include parts of the libraries it was compiled against (including the Prelude), so will be deeply tied to the actual version of those libraries it was compiled against. When you upgrade GHC, the libraries may change; even if the external interface of the libraries doesn't change, sometimes internal details may change because GHC optimised the code in the library differently.
We sometimes change the ABI (application binary interface) between versions of GHC. Code compiled with one version of GHC is not necessarily compatible with code compiled by a different version, even if you arrange to keep the same libraries.

Why doesn't GHC use shared libraries?

The subject of shared libraries has come up several times in the past — take a look through the mailing-list archives for some of the previous discussions. The upshot is that shared libraries wouldn't really buy much unless you really need to save the disk space: in all other considerations, static linking comes out better.

Unfortunately GHC-compiled libraries are very tightly coupled, which means it's unlikely you'd be able to swap out a shared library for a newer version unless it was compiled with exactly the same compiler and set of libraries as the old version.

I can't get string gaps to work

If you're also using CPP, beware of the known pitfall with string gaps mentioned in Section 4.12.3.1.

GHCi complains about missing symbols like CC_LIST when loading a previously compiled .o file.

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.

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).

I Can't run GHCi on Linux, because it complains about a missing libreadline.so.3.

The "correct" fix for this problem is to install the correct RPM for the particular flavour of Linux on your machine. If this isn't an option, however, there is a hack that might work: make a symbolic link from libreadline.so.4 to libreadline.so.3 in /usr/lib. We tried this on a SuSE 7.1 box and it seemed to work, but YMMV.

Solaris users may sometimes get link errors due to libraries needed by GNU Readline.

We suggest you try linking in some combination of the termcap, curses and ncurses libraries, by giving -ltermcap, -lcurses and -lncurses respectively. If you encounter this problem, we would appreciate feedback on it, since we don't fully understand what's going on here.

When I try to start ghci (probably one I compiled myself) it says ghc-5.02: not built for interactive use

To build a working ghci, you need to build GHC 5.02 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. Note that you really must build with exactly the same version of the compiler. Building 5.02 with 5.00.2, for example, may or may not give a working interactive system; it probably won't, and certainly isn't supported. Note also that you can build 5.02 with any older compiler, back to 4.08.1, if you don't want a working interactive system; that's OK, and supported.

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

You should use the -#include option to bring the correct prototype into scope (see Section 4.12.5).

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.

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 (although rumour has it that recent versions of FreeBSD changed the behavour to match other OSs). 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 in GHC versions prior to 5.02.2. GHC 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.

My program is failing with head [], or an array bounds error, or some other random error, and I have no idea how to find the bug. Can you help?

Compile your program with -prof -auto-all (make sure you have the profiling libraries installed), and run it with +RTS -xc -RTS to get a “stack trace” at the point at which the exception was raised. See Section 4.16.3 for more details.

How do I increase the heap size permanently for a given binary?

See Section 4.16.4.

I'm trying to compile my program for parallel execution with the -parallel, and GHC complains with an error like “failed to load interface file for Prelude”.

GHC doesn't ship with support for parallel execution, that support is provided separately by the GPH project.

When is it safe to use unsafePerformIO?

We'll give two answers to this question, each of which may be helpful. These criteria are not rigorous in any real sense (you'd need a formal semantics for Haskell in order to give a proper answer to this question), but should give you a feel for the kind of things you can and cannot do with unsafePerformIO.

It is safe to implement a function or API using unsafePerformIO if you could imagine also implementing the same function or API in Haskell without using unsafePerformIO (forget about efficiency, just consider the semantics).
In pure Haskell, the value of a function depends only on the values of its arguments (and free variables, if it has any). If you can implement the function using unsafePerformIO and still retain this invariant, then you're probably using unsafePerformIO in a safe way. Note that you need only consider the observable values of the arguments and result.

For more information, see this thread.

Why does linking take so long?

Linking a small program should take no more than a few seconds. Larger programs can take longer, but even linking GHC itself only takes 3-4 seconds on our development machines.

Long link times have been attributed to using Sun's linker on Solaris, as compared to GNU ld which appears to be much faster. So if you're on a Sun box, try switching to GNU ld. This article from the mailing list has more information.