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.
/usr/bin/ld: cannot open -lgmp: No such file or directoryThe 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).
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.
ghc-5.02: not built for interactive useTo 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.