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:
@@ -214,16 +214,6 @@
- option
-
-
-
- Pass option to the
- dependency generator.
-
-
-
- option
@@ -412,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.
@@ -553,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
@@ -652,12 +617,10 @@ $ cat foo.hspp
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.
@@ -668,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.
@@ -838,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).
@@ -849,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
@@ -949,23 +954,34 @@ $ 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.
+
+
+
+
+
+
+
+ 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 .
+
@@ -1034,6 +1050,28 @@ $ cat foo.hspp
/>).
+
+
+
+
+
+
+
+
+ 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.
+
+