X-Git-Url: http://git.megacz.com/?a=blobdiff_plain;f=docs%2Fusers_guide%2Fphases.xml;h=abe96b368162a228a9be7a577eb9e6d8c4a342a9;hb=f61baf76c9fa20aa972938384887bcb52151e76f;hp=cd18469e81638301e28f1a5ea0575a04fa070173;hpb=ba5729e5b8d80b3fcc8a477cb36d6a03800ac0dd;p=ghc-hetmet.git diff --git a/docs/users_guide/phases.xml b/docs/users_guide/phases.xml index cd18469..abe96b3 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 phase forcing 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. @@ -529,31 +543,6 @@ $ cat foo.hspp - - Options affecting the C compiler (if applicable) - - include-file options - C compiler options - GCC options - - If you are compiling with lots of foreign calls, you may - need to tell the C compiler about some - #include files. The Right Way to do this is to - add an INCLUDE pragma to the top of your source file - (): - -{-# INCLUDE <X/Xlib.h> #-} - - Sometimes this isn't convenient. In those cases there's an - equivalent command-line option: - -% ghc -c '-#include <X/Xlib.h>' Xstuff.lhs - - - - - - Options affecting code generation @@ -567,9 +556,7 @@ $ cat foo.hspp Use GHC's native code generator rather than compiling via C. This will compile faster (up to twice as fast), but may produce code that is slightly slower than - compiling via C. is the default - when optimisation is off (see ). + compiling via C. is the default. @@ -580,9 +567,8 @@ $ cat foo.hspp Compile via C instead of using the native code - generator. This is default for optimised compilations, - and on architectures for which GHC doesn't have a native - code generator. + generator. This is the default on architectures for which GHC + doesn't have a native code generator. @@ -600,17 +586,41 @@ $ cat foo.hspp + + + + + Generate object code. This is the default outside of + GHCi, and can be used with GHCi to cause object code to be + generated in preference to bytecode. + + + + + + + + + + Generate byte-code instead of object-code. This is + the default in GHCi. Byte-code can currently only be used + in the interactive interpreter, not saved to disk. This + option is only useful for reversing the effect of + . + + + + + Generate position-independent code (code that can be put into - shared libraries). This currently works on Mac OS X; it works on - PowerPC Linux when using the native code generator (-fasm). - It is not quite ready to be used yet for x86 Linux. - On Windows, position-independent code is never used, - and on PowerPC64 Linux, position-independent code is always used, - so the flag is a no-op on those platforms. + shared libraries). This currently works on Linux x86 and x86-64 when + using the native code generator (-fasm). + On Windows, position-independent code is never used + so the flag is a no-op on that platform. @@ -621,12 +631,9 @@ $ 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. - Note that this option also causes GHC to use shared libraries - when linking. + binary. + Note that using this option when linking causes GHC to link + against shared libraries. @@ -791,10 +798,12 @@ $ 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 tells GHC to link against shared Haskell libraries. + This flag only affects the selection of dependent libraries, not + the form of the current target (see -shared). + See on how to + create them. + Note that this option also has an effect on code generation (see above). @@ -802,6 +811,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 @@ -899,26 +951,143 @@ $ cat foo.hspp Parallelismparallelism on a multiprocessormultiprocessorSMP or multicoremulticore - machine. See . + 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). + + + + + + + + Link the program with the "eventlog" version of the + runtime system. A program linked in this way can generate + a runtime trace of events (such as thread start/stop) to a + binary file + program.eventlog, + which can then be interpreted later by various tools. See + for more information. + + + can be used + with . It is implied + by . + + + + + + + + + + + + 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 + (). + + + + + + + + + + + DLLs on Windows are typically linked to by linking to a corresponding + .lib or .dll.a - the so-called import library. + GHC will typically generate such a file for every DLL you create by compiling in + -shared 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. + + As long as you are happy to only be able to link to the DLL using + GetProcAddress and friends, you can supply the + flag to disable the creation of the import + library entirely. + + - More details on the use of "bound threads" in the - threaded runtime can be found in the Control.Concurrent module. + + + + + + + + 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 + -install_name to Apple's linker.) Ignored on other + platforms. @@ -928,7 +1097,6 @@ $ cat foo.hspp