GHC 5.02 Mini-FAQ
This page lists known problems for the 5.02 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). - Can't run GHCi on Linux, because it complains about a missing
libreadline.so.3.
Newer Linuxes (SuSE 7.1, possibly RH 7.X, possibly Mandrake 8.X) only come with libreadline.so.4. Installing from an appropriate RPM is a good way to avoid this problem. If you can't do this (perhaps because we don't have an RPM for your flavour of Linux), then you might be able to get things working by making a symbolic link from libreadline.so.4 to libreadline.so.3. We tried this on a SuSE 7.1 box and it seemed to work.
- 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 -#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.
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. We'll fix it after the 5.02 release.