</varlistentry>
<varlistentry>
+ <term>Do I have to recompile all my code if I upgrade
+ GHC?</term>
+ <listitem>
+ <para>Yes. There are two reasons for this:</para>
+ <itemizedlist>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </itemizedlist>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>Why doesn't GHC use shared libraries?</term>
<listitem>
<para>The subject of shared libraries has come up several
</varlistentry>
<varlistentry>
+ <term>The build fails in readline.</term>
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
<term>When I try to start ghci (probably one I compiled myself)
it says <literal>ghc-5.02: not built for interactive
use</literal></term>
with g++ and gcc 3.0.</para>
</listitem>
</varlistentry>
+
+ <varlistentry>
+ <term>My program is failing with <literal>head []</literal>, or
+ an array bounds error, or some other random error, and I have no
+ idea how to find the bug. Can you help?</term>
+
+ <listitem>
+ <para>Compile your program with <literal>-prof
+-auto-all</literal> (make sure you have the profiling libraries
+installed), and run it with <literal>+RTS -xc -RTS</literal> to get a
+“stack trace” at the point at which the exception was
+raised. See <xref linkend="rts-options-debugging"> for more
+details.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>How do I increase the heap size permanently for a given
+ binary?</term>
+ <listitem>
+ <para>See <xref linkend="rts-hooks">.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>I'm trying to compile my program for parallel execution
+ with the <option>-parallel</option>, and GHC complains with an
+ error like “failed to load interface file for
+ Prelude”.</term>
+ <listitem>
+ <para>GHC doesn't ship with support for parallel execution,
+ that support is provided separately by the <ulink
+ url="http://www.macs.hw.ac.uk/~dsg/gph/">GPH</ulink> project.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>When is it safe to use
+ <literal>unsafePerformIO</literal>?</term>
+ <listitem>
+ <para>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
+ <literal>unsafePerformIO</literal>.</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>It is safe to implement a function or API using
+ <literal>unsafePerformIO</literal> if you could imagine
+ also implementing the same function or API in Haskell
+ without using <literal>unsafePerformIO</literal> (forget
+ about efficiency, just consider the semantics).</para>
+ </listitem>
+
+ <listitem>
+ <para>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
+ <literal>unsafePerformIO</literal> and still retain this
+ invariant, then you're probably using
+ <literal>unsafePerformIO</literal> in a safe way. Note
+ that you need only consider the
+ <emphasis>observable</emphasis> values of the arguments
+ and result.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>For more information, see <ulink
+ url="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-July/003681.html">this
+ thread</ulink>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why does linking take so long?</term>
+ <listitem>
+ <para>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.</para>
+
+ <para>Long link times have been attributed to using Sun's
+ linker on Solaris, as compared to GNU <command>ld</command>
+ which appears to be much faster. So if you're on a Sun box,
+ try switching to GNU <command>ld</command>. <ulink
+ url="http://www.haskell.org/pipermail/glasgow-haskell-users/2002-November/004477.html">This
+ article</ulink> from the mailing list has more
+ information.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>If I explicitely set the buffering on a Handle to
+ "NoBuffering" I'm not able to enter EOF by typing
+ "Ctrl-D".</term>
+
+ <listitem>
+ <para>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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>If I print out a string using <literal>putStr</literal>,
+ and then attempt to read some input using
+ <literal>hGetLine</literal>, I don't see the output from the
+ <literal>putStr</literal>.</term>
+
+ <listitem>
+ <para>The <literal>stdout</literal> handle is line-buffered by
+ default, which means that output sent to the handle is only
+ flushed when a newline (<literal>/n</literal>) is output, the
+ buffer is full, or <literal>hFlush</literal> is called on the
+ Handle. The right way to make the text appear without sending
+ a newline is to use <literal>hFlush</literal>:</para>
+
+<programlisting>
+ import System.IO
+ main = do
+ putStr "how are you today? "
+ hFlush stdout
+ input <- hGetLine
+ ...</programlisting>
+
+ <para>You'll probably find that the behaviour differs when
+ using GHCi: the <literal>hFlush</literal> isn't necessary to
+ make the text appear. This is because in GHCi we turn off the
+ buffering on <literal>stdout</literal>, because this is
+ normally what you want in an interpreter: output appears as it
+ is generated.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>I can't get finalizers to work properly. My program
+ sometimes just prints
+ <literal><<loop>></literal>.</term>
+
+ <listitem>
+ <para>Chances are that your program is trying to write a
+ message to <literal>stdout</literal> or
+ <literal>stderr</literal> in the finalizer. Handles have
+ finalizers themselves, and since finalizers don't keep other
+ finalized values alive, the <literal>stdout</literal> and
+ <literal>stderr</literal> Handles may be finalized before your
+ finalizer runs. If this happens, your finalizer will block on
+ the handle, and probably end up receiving a
+ <literal>NonTermination</literal> exception (which is printed
+ as <literal><<loop>></literal>).</para>
+ </listitem>
+ </varlistentry>
+
+
+ <varlistentry>
+ <term>Does GHC implement any kind of extensible records?</term>
+
+ <listitem>
+ <para>No, extensible records are not implemented in GHC.
+ <ulink url="http://www.haskell.org/hugs/">Hugs</ulink>
+ 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.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Why do I get errors about missing include files when
+ compiling with <option>-O</option> or
+ <option>-prof</option>?</term>
+
+ <listitem>
+ <para>Certain options, such as <option>-O</option>, turn on
+ via-C compilation, instead of using the native code generator.
+ Include files named by <option>-#include</option> options
+ or in <literal>foreign import</literal> declarations are only
+ used in via-C compilation mode. See <xref
+ linkend="finding-header-files"> for more details.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>How do I compile my program for profiling without
+ overwriting the object files and <literal>hi</literal> files
+ I've already built?</term>
+ <listitem>
+ <para>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:</para>
+
+ <screen>ghc --make -prof -o foo-prof -osuf p.o -hisuf p.hi Main</screen>
+
+ <para>See <xref linkend="options-output"> for more details on
+ the <option>-osuf</option> and <option>-hisuf</option>
+ options.</para>
+ </listitem>
+ </varlistentry>
+
</variablelist>
+
</chapter>
projects / ghc-hetmet.git / blobdiff