Changes between Version 10 and Version 11 of FAQ


Ignore:
Timestamp:
Jan 20, 2006 10:45:46 AM (8 years ago)
Author:
simonmar
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • FAQ

    v10 v11  
    1 = The GHC FAQ = 
    2  
    3 Please feel free to add stuff here (login '''guest''', password '''guest'''). 
    4  
    5 This page is rather long.  We've started to add some sub-headings, but would welcome your help in making it better organsised. 
    6  
    7 --------------------------------------- 
    8 = GHC on particular platforms = 
    9  
    10 == How do I port GHC to platform X? == 
    11  
    12 There are two distinct possibilities: either 
    13  
    14  * 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. 
    15  
    16  * 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). 
    17  
    18 Both ways require you to bootstrap 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. 
    19  
    20 The [http://www.haskell.org/ghc/docs/latest/html/building Building Guide] has all the details on how to bootstrap GHC on a new platform. 
    21  
    22  
    23 == GHC on Linux == 
    24  
    25 === I Can't run GHCi on Linux, because it complains about a missing {{{libreadline.so.3}}}. === 
    26  
    27 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. 
    28  
    29 == GHC on Solaris == 
    30 === Solaris users may sometimes get link errors due to libraries needed by GNU Readline. === 
    31  
    32 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. 
    33 The build fails in readline. 
    34  
    35 It has been reported that if you have multiple versions of the readline library installed on Linux, then this may cause the build to fail. If you have multiple versions of readline, try uninstalling all except the most recent version. 
    36  
    37 == GHC on Windows == 
    38 === My program that uses a really large heap crashes on Windows. === 
    39  
    40 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). 
    41  
    42 === I can't use readline under GHCi on Windows === 
    43  
    44 In order to load the readline package under GHCi on Windows, you need to make a version of the readline library that GHCi can load. Instructions for GHC 6.2.2. are here. 
    45  
    46 === Ctrl-C doesn't work on Windows === 
    47  
    48 When running GHC under a Cygwin shell on Windows, Ctrl-C sometimes doesn't work. The workaround is to use Ctrl-Break instead. 
    49  
    50 == Why isn't GHC available for .NET? == 
    51  
    52  
    53 It wouldd make a lot of sense to give GHC a .NET back end, and it's a 
    54 question that comes up regularly.  The reason that we haven't done it 
    55 here, at GHC HQ, is because it's a more substantial undertaking than 
    56 might at first appear (see below).  Furthermore, it'd permanently add a 
    57 complete new back-end platform for us to maintain.  Given our rather 
    58 limited development effort, we have so far not bitten 
    59 the bullet, and we have no immediate plans to do so. 
    60  
    61 It would be a good, well-defined project for someone else to tackle, and 
    62 we would love to see it done. There is some good groundwork already done: 
    63  
    64  * Sigbjorn Finne did a simple interop implementation that allows a 
    65    Haskell program to be compiled to native code (as now) but to call 
    66    .NET programs via a variant of the FFI.  I don't think this work is 
    67    in active use, and I'd be surprised if it worked out of the box, but 
    68    it could probably be revived with modest effort 
    69  
    70  * Andre Santos and his colleagues at UFPE in Brazil are working on a 
    71    .NET back end, that generates CLR IL, though I don't know where they 
    72    are up to. 
    73  
    74  * Nigel Perry and Oliver Hunt have a Haskell.NET prototype that works 
    75    using GHC to compile to Core, and then compiling Core to NET.  I'm 
    76    not sure what stage it is at. 
    77  
    78  * GHC.Net would be extra attractive if there was a Visual Studio 
    79    integration for GHC. Substantial progress on this has been made in 
    80    2004 by Simon Marlow, Krasimir Angelov, and Andre Santos and 
    81    colleagues. 
    82  
    83 There may be others that I don't know of.  If anyone wants to join in 
    84 this effort, do contact the above folk.  And please keep us informed! 
    85  
    86 Here's a summary of why it's a non-trivial thing to do: 
    87  
    88  * The first thing is to generate native CLR Intermediate Language 
    89    (IL). That's not really hard.  Requires thinking about 
    90    representations for thunks and functions, and it may not be 
    91    particularly efficient, but it can surely be done.  An open question 
    92    is about whether to generate verifiable IL or not.  The trouble here 
    93    is that Haskell's type system is more expressive than the CLR's in 
    94    some ways, notably the use of higher-kinded type variables.  So, to 
    95    generate verifiable IL one is bound to need some run-time casts, and 
    96    it's not clear how to minimise these. 
    97  
    98 At first blush this is *all* you need do.  But it isn't! 
    99  
    100  * Next, you need to think about how to inter-operate with .NET 
    101    libraries.  You don't really want to write "foreign import..." for 
    102    each and every import.  You'd like GHC to read the CLR meta-data 
    103    directly.  But there are lots of tricky issues here; see the paper 
    104    that Mark Shields and I wrote about "Object-oriented style 
    105    overloading for Haskell". 
    106  
    107  * Now you need to figure out how to implement GHC's primitive operations: 
    108     * the I/O monad 
    109     * arbitrary precision arithmetic 
    110     * concurrency 
    111     * exceptions 
    112     * finalisers 
    113     * stable pointers 
    114     * software transactional memory 
    115    Not all of these are necessary, of course, but many are used in the 
    116    libraries.  The CLR supports many of them (e.g. concurrency) but 
    117    with a very different cost model. 
    118  
    119  * Last, you have to figure out what to do for the libraries.  GHC has 
    120    a pretty large library, and you either have to implement the primops 
    121    on which the library is based (see previous point), or re-implement 
    122    it.  For example, GHC's implementation of I/O uses mutable state, 
    123    concurrency, and more besides. For each module, you need to decide 
    124    either to re-implement it using .NET primitives, or to implement the 
    125    stuff the module is based on. 
    126  
    127 These challenges are mostly broad rather than deep.  But to get a 
    128 production quality implementation that runs a substantial majority of 
    129 Haskell programs "out of the box" requires a decent stab at all of them. 
    130  
    131 --------------------------------------- 
    132 = Other frequently asked questions = 
    133  
    134 == When do other Haskell threads get blocked by an FFI call? == 
    135  
    136 ||               || safe || unsafe || 
    137 || -threaded     || NO   ||YES     || 
    138 || no -threaded  || YES  ||YES     || 
    139  
    140 The `-threaded` flag (given when linking; see the  
    141 [http://www.haskell.org/ghc/docs/latest/html/users_guide/flag-reference.html manual]) 
    142 allows other Haskell threads to run concurrently with a thread making an FFI call. 
    143 This nice behaviour does not happen for foreign calls marked as `unsafe` (see 
    144 the [http://www.cse.unsw.edu.au/~chak/haskell/ffi/ FFI Addendum]). 
    145  
    146 There used to be another modifier, `threadsafe`, which is now deprecated.  Use `safe` instead. 
    147  
    148  
    149 == Do I have to recompile all my code if I upgrade GHC? == 
    150  
    151 Yes. There are two reasons for this: 
    152  
    153  * 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. 
    154  * 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. 
    155  
    156 == Why doesn't GHC use shared libraries? == 
    157  
    158 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. 
    159  
    160 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. 
    161  
    162 == I can't get string gaps to work == 
    163  
    164 If you're also using CPP, beware of the known pitfall with string gaps mentioned in [http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#cpp-string-gaps Section 4.10.3.1, “CPP and string gaps”]. 
    165  
    166 == GHCi complains about missing symbols like CC_LIST when loading a previously compiled .o file. == 
    167  
    168 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. 
    169  
    170 == Linking a program causes the following error on Linux: {{{/usr/bin/ld: cannot open -lgmp: No such file or directory}}} == 
    171  
    172 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). 
    173  
    174 == When I try to start ghci (probably one I compiled myself) it says {{{ghc-5.02: not built for interactive use}}} == 
    175  
    176 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. 
    177  
    178 == When I use a foreign function that takes or returns a float, it gives the wrong answer, or crashes. == 
    179  
    180 You should use the {{{-#include}}} option to bring the correct prototype into scope (see [http://www.haskell.org/ghc/docs/latest/html/users_guide/options-phases.html#options-C-compiler Section 4.10.5, “Options affecting the C compiler (if applicable)”]). 
    181  
    182 == GHC doesn't like filenames containing +. == 
    183  
    184 Indeed not. You could change {{{+}}} to {{{p}}} or {{{plus}}}. 
    185  
    186 == When I open a FIFO (named pipe) and try to read from it, I get EOF immediately. == 
    187  
    188 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 behaviour 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. 
    189 When I foreign import a function that returns char or short, I get garbage back. 
    190  
    191 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. 
    192  
    193 == 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? == 
    194  
    195 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 [http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-options-debugging Section 4.14.4, “RTS options for hackers, debuggers, and over-interested souls”] for more details. 
    196  
    197 == How do I increase the heap size permanently for a given binary? == 
    198  
    199 See [http://www.haskell.org/ghc/docs/latest/html/users_guide/runtime-control.html#rts-hooks Section 4.14.5, ““Hooks” to change RTS behaviour”]. 
    200  
    201 == 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”. == 
    202  
    203 GHC doesn't ship with support for parallel execution, that support is provided separately by the [http://www.macs.hw.ac.uk/~dsg/gph/ GPH] project. 
    204  
    205 == When is it safe to use {{{unsafePerformIO}}}? == 
    206  
    207 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. 
    208  
    209  * 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). 
    210  * 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. 
    211  
    212 For more information, see [http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003681.html this thread]. 
    213  
    214 == Why does linking take so long? == 
    215  
    216 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. 
    217  
    218 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. [http://www.haskell.org/pipermail/glasgow-haskell-users/2002-November/004477.html This article] from the mailing list has more information. 
    219  
    220 == If I explicitly set the buffering on a Handle to {{{NoBuffering}}} I'm not able to enter EOF by typing "Ctrl-D". == 
    221  
    222 This is a consequence of Unixy terminal semantics. Unix does line buffering on terminals in the kernel as part of the terminal processing, unless you turn it off. However, the Ctrl-D processing is also part of the terminal processing which gets turned off when the kernel line buffering is disabled. So GHC tries its best to get NoBuffering semantics by turning off the kernel line buffering, but as a result you lose Ctrl-D. C'est la vie. 
    223  
    224 == If I print out a string using {{{putStr}}}, and then attempt to read some input using {{{hGetLine}}}, I don't see the output from the {{{putStr}}}. == 
    225  
    226 The {{{stdout}}} handle is line-buffered by default, which means that output sent to the handle is only flushed when a newline (/n) is output, the buffer is full, or {{{hFlush}}} is called on the {{{Handle}}}. The right way to make the text appear without sending a newline is to use {{{hFlush}}}: 
    227  
    228 {{{ 
    229       import System.IO 
    230       main = do 
    231         putStr "how are you today? " 
    232         hFlush stdout 
    233         input &- hGetLine 
    234         ... 
    235 }}} 
    236  
    237 You'll probably find that the behaviour differs when using GHCi: the hFlush isn't necessary to make the text appear. This is because in GHCi we turn off the buffering on stdout, because this is normally what you want in an interpreter: output appears as it is generated. 
    238  
    239 == I can't get finalizers to work properly. My program sometimes just prints {{{<<loop>>}}}. == 
    240  
    241 Chances are that your program is trying to write a message to stdout or stderr in the finalizer. Handles have finalizers themselves, and since finalizers don't keep other finalized values alive, the stdout and stderr Handles may be finalized before your finalizer runs. If this happens, your finalizer will block on the handle, and probably end up receiving a NonTermination exception (which is printed as {{{<<loop>>}}}). 
    242  
    243 == Does GHC implement any kind of extensible records? == 
    244  
    245 No, extensible records are not implemented in GHC. [http://www.haskell.org/hugs/ Hugs] implements TRex, one extensible record variant. The problem is that the record design space is large, and seems to lack local optima. And all reasonable variants break backward compatibility. As a result, nothing much happens. 
    246  
    247 == Why do I get errors about missing include files when compiling with -O or -prof? == 
    248  
    249 Certain options, such as -O, turn on via-C compilation, instead of using the native code generator. Include files named by -#include options or in foreign import declarations are only used in via-C compilation mode. See [http://www.haskell.org/ghc/docs/latest/html/users_guide/sec-ffi-ghc.html#finding-header-files Section 8.2.2.1, “Finding Header files”] for more details. 
    250  
    251 == How do I compile my program for profiling without overwriting the object files and hi files I've already built? == 
    252  
    253 You can select alternative suffixes for object files and interface files, so you can have several builds of the same code coexisting in the same directory. For example, to compile with profiling, you might do this: 
    254  
    255 {{{ 
    256     ghc --make -prof -o foo-prof -osuf p.o -hisuf p.hi Main 
    257 }}} 
    258  
    259 See [http://www.haskell.org/ghc/docs/latest/html/users_guide/separate-compilation.html#options-output Section 4.6.4, “Redirecting the compilation output(s)”] for more details on the {{{-osuf}}} and {{{-hisuf}}} options. 
    260  
    261 == I get an error message from GHCi about a "{{{duplicate definition for symbol __module_registered}}}" == 
    262  
    263 An error message like this: 
    264  
    265 {{{ 
    266     GHCi runtime linker: fatal error: I found a duplicate definition for symbol 
    267            __module_registered 
    268         whilst processing object file 
    269            /usr/local/lib/ghc-6.2/HSfgl.o 
    270 }}} 
    271  
    272 probably indicates that when building a library for GHCi ({{{HSfgl.o}}} in the above example), you should use the {{{-x}}} option to {{{ld}}}. 
    273  
    274  
    275 = Optimization issues = 
    276  
    277 == My program spent too much time doing garbage collection == 
    278  
    279 Add the "+RTS -A10m" option to the command line when you run your program. This should sufficiently decrease GC times. You can also add to your program C module containing statement  
    280  
    281 {{{ 
    282 char *ghc_rts_opts = "-A10m"; 
    283 }}} 
    284  
    285 to force your program use this setting on each run 
     1We have moved this page to the main Haskell Wiki, please update your links: [http://haskell.org/haskellwiki/GHC:FAQ]