X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;ds=sidebyside;f=docs%2Fusers_guide%2Fphases.xml;h=ac71b97b7abea97b1c433a93d2e59d2839619926;hb=901d7795d31fb6706ffcb7e522160feddf4260b7;hp=3ac9ef27e27a6d6a0fd74e44c1e7717013fa105d;hpb=3c22606bf3114747deeae0a8a1d5832ee834d9d1;p=ghc-hetmet.git
diff --git a/docs/users_guide/phases.xml b/docs/users_guide/phases.xml
index 3ac9ef2..ac71b97 100644
--- a/docs/users_guide/phases.xml
+++ b/docs/users_guide/phases.xml
@@ -113,7 +113,19 @@
-
+
+
+ cmd
+
+
+
+ Use cmd as the
+ program to use for embedding manifests on Windows. Normally this
+ is the program windres, which is supplied with a
+ GHC installation. See in .
+
+
@@ -121,7 +133,7 @@
Forcing options to a particular phaseforcing GHC-phase options
- Options can be forced through to a particlar compilation
+ Options can be forced through to a particular compilation
phase, using the following flags:
@@ -202,12 +214,14 @@
- option
-
+ option
+
- Pass option to the
- dependency generator.
+ Pass option to
+ windres when embedding manifests on Windows.
+ See in .
@@ -388,7 +402,7 @@ $ cat foo.hspp
This symbol is defined when pre-processing Haskell
(input) and pre-processing C (GHC output). Since GHC from
- verion 4.00 now supports concurrent haskell by default,
+ version 4.00 now supports concurrent haskell by default,
this symbol is always defined.
@@ -644,10 +658,7 @@ $ cat foo.hspp
When generating code, assume that entities imported from a
different package will reside in a different shared library or
- binary. This currently works on Mac OS X; it works on PowerPC Linux when
- using the native code generator. As with ,
- x86 Linux support is not quite ready yet. Windows is not supported,
- and it is a no-op on PowerPC64 Linux.
+ binary.Note that this option also causes GHC to use shared libraries
when linking.
@@ -814,10 +825,10 @@ $ cat foo.hspp
- Tell the linker to use shared Haskell libraries, if
- available (this option is only supported on Mac OS X at the
- moment, and also note that your distribution of GHC may
- not have been supplied with shared libraries).
+ This flag switches to shared Haskell libraries for
+ linking. See on how to
+ create them.
+
Note that this option also has an effect on
code generation (see above).
@@ -825,6 +836,49 @@ $ cat foo.hspp
+
+
+
+
+ Instead of creating an executable, GHC produces a
+ shared object with this linker flag. Depending on the
+ operating system target, this might be an ELF DSO, a Windows
+ DLL, or a Mac OS dylib. GHC hides the operating system
+ details beneath this uniform flag.
+
+ The flags / control whether the
+ resulting shared object links statically or dynamically to
+ Haskell package libraries given as option. Non-Haskell
+ libraries are linked as gcc would regularly link it on your
+ system, e.g. on most ELF system the linker uses the dynamic
+ libraries when found.
+
+ Object files linked into shared objects must be
+ compiled with , see
+
+ When creating shared objects for Haskell packages, the
+ shared object must be named properly, so that GHC recognizes
+ the shared object when linked against this package. See
+ shared object name mangling.
+
+
+
+
+
+
+
+
+
+
+ This flag selects one of a number of modes for finding shared
+ libraries at runtime. See for
+ a description of each mode.
+
+
+
+
+
+ specifying your own main function
@@ -925,23 +979,77 @@ $ cat foo.hspp
machine. See .
The ability to make a foreign call that does not
- block all other Haskell threads.
-
- The ability to invoke foreign exported Haskell
- functions from multiple OS threads.
+ block all other Haskell threads, and to invoke
+ foreign-exported Haskell functions from multiple OS
+ threads. See .
+
+
- With , calls to foreign
- functions are made using the same OS thread that created the
- Haskell thread (if it was created by a call to a foreign
- exported Haskell function), or an arbitrary OS thread
- otherwise (if the Haskell thread was created by
- forkIO).
-
- More details on the use of "bound threads" in the
- threaded runtime can be found in the Control.Concurrent module.
+
+
+
+
+
+
+
+ On Windows, GHC normally generates a
+ manifestmanifest
+ file when linking a binary. The
+ manifest is placed in the file
+ prog.exe.manifest
+ where prog.exe is the name of the
+ executable. The manifest file currently serves just one purpose:
+ it disables the "installer detection"installer detection
+ 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.
+
+ 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.
+
+ The disables generation of
+ the manifest file. One reason to do this would be if you had
+ a manifest file of your own, for example.
+
+ In the future, GHC might use the manifest file for more things,
+ such as supplying the location of dependent DLLs.
+
+ also implies
+ , see below.
+
+
+
+
+
+
+
+
+
+
+ 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
+ windreswindres
+ ; to see exactly what GHC does to embed the manifest,
+ use the flag. A GHC installation comes with
+ its own copy of windres for this reason.
+
+ See also () and
+ ().