+ <varlistentry>
+ <term>
+ <option>-rtsopts</option>
+ <indexterm><primary><option>-rtsopts</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>
+ This option affects the processing of RTS control options given either
+ on the command line or via the <envar>GHCRTS</envar> environment variable.
+ There are three possibilities:
+ </para>
+ <variablelist>
+ <varlistentry>
+ <term><option>-rtsopts=none</option></term>
+ <listitem>
+ <para>
+ Disable all processing of RTS options.
+ If <option>+RTS</option> appears anywhere on the command
+ line, then the program will abort with an error message.
+ If the <envar>GHCRTS</envar> environment variable is
+ set, then the program will emit a warning message,
+ <envar>GHCRTS</envar> will be ignored, and the program
+ will run as normal.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-rtsopts=some</option></term>
+ <listitem>
+ <para>[this is the default setting] Enable
+ only the "safe" RTS options: (Currently
+ only <option>-?</option>
+ and <option>--info</option>.) Any other RTS options
+ on the command line or in the <envar>GHCRTS</envar>
+ environment variable causes the program with to abort
+ with an error message.
+ </para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term><option>-rtsopts=all</option>, or
+ just <option>-rtsopts</option></term>
+ <listitem>
+ <para>
+ Enable <emphasis>all</emphasis> RTS option
+ processing, both on the command line and through
+ the <envar>GHCRTS</envar> environment variable.
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+ <para>
+ In GHC 6.12.3 and earlier, the default was to process all
+ RTS options. However, since RTS options can be used to
+ write logging data to arbitrary files under the security
+ context of the running program, there is a potential
+ security problem. For this reason, GHC 7.0.1 and later
+ default to <option>-rtsops=some</option>.
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-with-rtsopts</option>
+ <indexterm><primary><option>-with-rtsopts</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>
+ This option allows you to set the default RTS options at link-time. For example,
+ <option>-with-rtsopts="-H128m"</option> sets the default heap size to 128MB.
+ This will always be the default heap size for this program, unless the user overrides it.
+ (Depending on the setting of the <option>-rtsopts</option> option, the user might
+ not have the ability to change RTS options at run-time, in which case
+ <option>-with-rtsopts</option> would be the <emphasis>only</emphasis> way to set
+ them.)
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-gen-manifest</option>
+ <indexterm><primary><option>-fno-gen-manifest</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>On Windows, GHC normally generates a
+ <firstterm>manifest</firstterm><indexterm><primary>manifest</primary>
+ </indexterm>file when linking a binary. The
+ manifest is placed in the file
+ <literal><replaceable>prog</replaceable>.exe.manifest</literal>
+ where <replaceable>prog.exe</replaceable> is the name of the
+ executable. The manifest file currently serves just one purpose:
+ it disables the "installer detection"<indexterm><primary>installer detection</primary>
+ </indexterm>in Windows Vista that
+ attempts to elevate privileges for executables with certain names
+ (e.g. names containing "install", "setup" or "patch"). Without the
+ manifest file to turn off installer detection, attempting to run an
+ executable that Windows deems to be an installer will return a
+ permission error code to the invoker. Depending on the invoker,
+ the result might be a dialog box asking the user for elevated
+ permissions, or it might simply be a permission denied
+ error.</para>
+
+ <para>Installer detection can be also turned off globally for the
+ system using the security control panel, but GHC by default
+ generates binaries that don't depend on the user having disabled
+ installer detection.</para>
+
+ <para>The <option>-fno-gen-manifest</option> disables generation of
+ the manifest file. One reason to do this would be if you had
+ a manifest file of your own, for example.</para>
+
+ <para>In the future, GHC might use the manifest file for more things,
+ such as supplying the location of dependent DLLs.</para>
+
+ <para><option>-fno-gen-manifest</option> also implies
+ <option>-fno-embed-manifest</option>, see below.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-embed-manifest</option>
+ <indexterm><primary><option>-fno-embed-manifest</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>The manifest file that GHC generates when linking a binary on
+ Windows is also embedded in the executable itself, by default.
+ This means that the binary can be distributed without having to
+ supply the manifest file too. The embedding is done by running
+ <literal>windres</literal><indexterm><primary><literal>windres</literal></primary>
+ </indexterm>; to see exactly what GHC does to embed the manifest,
+ use the <option>-v</option> flag. A GHC installation comes with
+ its own copy of <literal>windres</literal> for this reason.</para>
+
+ <para>See also <option>-pgmwindres</option> (<xref
+ linkend="replacing-phases" />) and
+ <option>-optwindres</option> (<xref
+ linkend="forcing-options-through"
+ />).</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fno-shared-implib</option>
+ <indexterm><primary><option>-fno-shared-implib</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>DLLs on Windows are typically linked to by linking to a corresponding
+ <literal>.lib</literal> or <literal>.dll.a</literal> - the so-called import library.
+ GHC will typically generate such a file for every DLL you create by compiling in
+ <literal>-shared</literal> mode. However, sometimes you don't want to pay the
+ disk-space cost of creating this import library, which can be substantial - it
+ might require as much space as the code itself, as Haskell DLLs tend to export
+ lots of symbols.</para>
+
+ <para>As long as you are happy to only be able to link to the DLL using
+ <literal>GetProcAddress</literal> and friends, you can supply the
+ <option>-fno-shared-implib</option> flag to disable the creation of the import
+ library entirely.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-dylib-install-name <replaceable>path</replaceable></option>
+ <indexterm><primary><option>-dylib-install-name</option></primary>
+ </indexterm>
+ </term>
+ <listitem>
+ <para>On Darwin/MacOS X, dynamic libraries are stamped at build time with an
+ "install name", which is the ultimate install path of the library file.
+ Any libraries or executables that subsequently link against it will pick
+ up that path as their runtime search location for it. By default, ghc sets
+ the install name to the location where the library is built. This option
+ allows you to override it with the specified file path. (It passes
+ <literal>-install_name</literal> to Apple's linker.) Ignored on other
+ platforms.</para>