You may specify that a different program be used for one of the phases of the compilation system, in place of whatever the ghc has wired into it. For example, you might want to try a different assembler. The following options allow you to change the external program used for a given compilation phases:
Options can be forced through to a particlar compilation phase, using the following flags:
So, for example, to force an -Ewurble option to the assembler, you would tell the driver -opta-Ewurble (the dash before the E is required).
GHC is itself a Haskell program, so if you need to pass options directly to GHC's runtime system you can enclose them in +RTS ... -RTS (see Section 4.16).
The C pre-processor cpp is run over your Haskell code only if the -cpp option is given. Unless you are building a large system with significant doses of conditional compilation, you really shouldn't need it.
Define macro symbol in the usual way. NB: does not affect -D macros passed to the C compiler when compiling via C! For those, use the -optc-Dfoo hack… (see Section 4.12.2).
Undefine macro symbol in the usual way.
Specify a directory in which to look for #include files, in the usual C way.
The GHC driver pre-defines several macros when processing Haskell source code (.hs or .lhs files):
If defined, this means that GHC supports the language defined by the Haskell 98 report.
In GHC 4.04 and later, the __HASKELL__ macro is defined as having the value 98.
If defined to n, that means GHC supports the Haskell language defined in the Haskell report version 1.n. Currently 5. This macro is deprecated, and will probably disappear in future versions.
For version n of the GHC system, this will be #defined to 100n. For example, for version 5.00, it is 500.
With any luck, __GLASGOW_HASKELL__ will be undefined in all other implementations that support C-style pre-processing.
(For reference: the comparable symbols for other systems are: __HUGS__ for Hugs and __HBC__ for Chalmers.)
NB. This macro is set when pre-processing both Haskell source and C source, including the C source generated from a Haskell module (i.e. .hs, .lhs, .c and .hc files).
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, this symbol is always defined.
Only defined when -parallel is in use! This symbol is defined when pre-processing Haskell (input) and pre-processing C (GHC output).
A small word of warning: -cpp is not friendly to “string gaps”.. In other words, strings such as the following:
strmod = "\ \ p \ \ " |
don't work with -cpp; /usr/bin/cpp elides the backslash-newline pairs.
However, it appears that if you add a space at the end of the line, then cpp (at least GNU cpp and possibly other cpps) leaves the backslash-space pairs alone and the string gap works as expected.
If you are compiling with lots of foreign calls, you may need to tell the C compiler about some #include files. There is no real pretty way to do this, but you can use this hack from the command-line:
% ghc -c '-#include <X/Xlib.h>' Xstuff.lhs |
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. -fasm is the default when optimisation is off (see Section 4.11).
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.
GHC has to link your code with various libraries, possibly including: user-supplied, GHC-supplied, and system-supplied (-lm math library, for example).
Link in the lib library. On Unix systems, this will be in a file called liblib.a or liblib.so which resides somewhere on the library directories path.
Because of the sad state of most UNIX linkers, the order of such options does matter. If library foo requires library bar, then in general -lfoo should come before -lbar on the command line.
If you are using a Haskell “package” (see Section 4.10), don't forget to add the relevant -package option when linking the program too: it will cause the appropriate libraries to be linked in with the program. Forgetting the -package option will likely result in several pages of link errors.
Where to find user-supplied libraries… Prepend the directory dir to the library directories path.
Tell the linker to split the single object file that would normally be generated into multiple object files, one per top-level Haskell function or type in the module. We use this feature for building GHC's libraries libraries (warning: don't use it unless you know what you're doing!).
Tell the linker to avoid shared Haskell libraries, if possible. This is the default.
Tell the linker to use shared Haskell libraries, if available (this option is only supported on Windows at the moment, and also note that your distribution of GHC may not have been supplied with shared libraries).
In the event you want to include ghc-compiled code as part of another (non-Haskell) program, the RTS will not be supplying its definition of main() at link-time, you will have to. To signal that to the driver script when linking, use -no-hs-main.
Notice that since the command-line passed to the linker is rather involved, you probably want to use ghc to do the final link of your `mixed-language' application. This is not a requirement though, just try linking once with -v on to see what options the driver passes through to the linker.