2 <title>Running GHC on Win32 systems</title>
6 Starting GHC on Win32 platforms</title>
9 The installer that installs GHC on Win32 also sets up the file-suffix associations
10 for ".hs" and ".lhs" files so that double-clicking them starts <command>ghci</command>.
13 One little hitch happens if you right-click on a file, select "Open With..." and
14 then pick <command>ghci</command>. If the filename has spaces in, what will happen is
15 that GHC will get invoked like this:
17 c:\ghc\bin\ghci \Documents and Settings\MyFile.lhs
19 So it looks to GHC as if there are three arguments, "\Documents", "and", and "Settings\MyFile.lhs".
21 <para> Solution: don't use "Open With...", avoid spaces in file names,
22 or fiddle with the appropriate registry setting:
24 HKEY_CLASSES_ROOT\Unknown\shell\openas\command
26 Notice how the "%1" argument is quoted (or not).
28 <para> This problem doesn't occur when double-clicking.
36 Using GHC (and other GHC-compiled executables) with cygwin</title>
39 <title>Background</title> <para>The cygwin tools aim to provide a
40 unix-style API on top of the windows libraries, to facilitate ports of
41 unix software to windows. To this end, they introduce a unix-style
42 directory hierarchy under some root directory (typically
43 <filename>/</filename> is <filename>C:\cygwin\</filename>). Moreover,
44 everything built against the cygwin API (including the cygwin tools
45 and programs compiled with cygwin's ghc) will see / as the root of
46 their file system, happily pretending to work in a typical unix
47 environment, and finding things like <filename>/bin</filename> and <filename>/usr/include</filename> without
48 ever explicitly bothering with their actual location on the windows
49 system (probably <filename>C:\cygwin\bin</filename> and <filename>C:\cygwin\usr\include</filename>).
53 <sect2><title>The problem</title>
54 <para>GHC, by default, no longer depends on cygwin, but is a native
55 windows program. It is built using mingw, and it uses mingw's ghc
56 while compiling your Haskell sources (even if you call it from
57 cygwin's bash), but what matters here is that - just like any other
58 normal windows program - neither GHC nor the executables it produces
59 are aware of cygwin's pretended unix hierarchy. GHC will happily
60 accept either '/' or '\' as path separators, but it won't know where
61 to find <filename>/home/joe/Main.hs</filename> or <filename>/bin/bash</filename>
62 or the like. This causes all
63 kinds of fun when GHC is used from within cygwin's bash, or in
64 make-sessions running under cygwin.
68 <sect2><title>Things to do</title>
71 <para> Don't use absolute paths in make, configure & co if there is any chance
72 that those might be passed to GHC (or to GHC-compiled programs). Relative
73 paths are fine because cygwin tools are happy with them and GHC accepts
74 '/' as path-separator. And relative paths don't depend on where cygwin's
75 root directory is located, or on which partition or network drive your source
76 tree happens to reside, as long as you 'cd' there first.
80 <para> If you have to use absolute paths (beware of the innocent-looking
81 <literal>ROOT=`pwd`</literal> in makefile hierarchies or configure scripts), cygwin provides
82 a tool called <command>cygpath</command> that can convert cygwin's unix-style paths to their
83 actual windows-style counterparts. Many cygwin tools actually accept
84 absolute windows-style paths (remember, though, that you either need
85 to escape '\' or convert '\' to '/'), so you should be fine just using those
86 everywhere. If you need to use tools that do some kind of path-mangling
87 that depends on unix-style paths (one fun example is trying to interpret ':'
88 as a separator in path lists..), you can still try to convert paths using
89 <command>cygpath</command> just before they are passed to GHC and friends.
93 <para> If you don't have <command>cygpath</command>, you probably don't have cygwin and hence
94 no problems with it... unless you want to write one build process for several
95 platforms. Again, relative paths are your friend, but if you have to use
96 absolute paths, and don't want to use different tools on different platforms,
97 you can simply write a short Haskell program to print the current directory
98 (thanks to George Russell for this idea): compiled with GHC, this will give
99 you the view of the file system that GHC depends on (which will differ
100 depending on whether GHC is compiled with cygwin's gcc or mingw's
101 gcc or on a real unix system..) - that little program can also deal with
102 escaping '\' in paths. Apart from the banner and the startup time,
103 something like this would also do:
105 $ echo "Directory.getCurrentDirectory >>= putStrLn . init . tail . show " | ghci
113 <sect1 id="win32-dlls">
114 <Title>Building and using Win32 DLLs
118 <IndexTerm><Primary>Dynamic link libraries, Win32</Primary></IndexTerm>
119 <IndexTerm><Primary>DLLs, Win32</Primary></IndexTerm>
120 On Win32 platforms, the compiler is capable of both producing and using
121 dynamic link libraries (DLLs) containing ghc-compiled code. This
122 section shows you how to make use of this facility.
126 Until recently, <Command>strip</Command> didn't work reliably on DLLs, so you
127 should test your version with care, or make sure you have the latest
128 binutils. Unfortunately, we don't know exactly which version of binutils
129 cured the problem (it was supposedly fixed some years ago).
133 <Sect2 id="win32-dlls-link">
134 <Title>Linking with DLLs
138 The default on Win32 platforms is to link applications in such a way
139 that the executables will use the Prelude and system libraries DLLs,
140 rather than contain (large chunks of) them. This is transparent at the
148 main = putStrLn "hello, world!"
149 sh$ ghc -o main main.hs
150 ghc: module version changed to 1; reason: no old .hi file
153 -rwxr-xr-x 1 544 everyone 4608 May 3 17:11 main.exe*
161 will give you a binary as before, but the <Filename>main.exe</Filename>
162 generated will use the Prelude and RTS DLLs instead of linking them in
167 4K for a <Literal>"hello, world"</Literal> application—not bad, huh? :-)
172 <Sect2 id="win32-dlls-linking-static">
173 <Title>Not linking with DLLs
174 <IndexTerm><Primary>-static option (Win32)</Primary></IndexTerm></Title>
177 If you want to build an executable that doesn't depend on any
178 ghc-compiled DLLs, use the <Option>-static</Option> option to link in
183 Notice that you cannot mix code that has been compiled with
184 <Option>-static</Option> and not, so you have to use the <Option>-static</Option>
185 option on all the Haskell modules that make up your application.
190 <Sect2 id="win32-dlls-create">
191 <Title>Creating a DLL
195 <emphasis>Making libraries into DLLs doesn't work on Windows at the
196 moment (and is no longer supported); however, all the machinery is
197 still there. If you're interested, contact the GHC team. Note that
198 building an entire Haskell application as a DLL is still supported
199 (it's just inter-DLL Haskell calls that don't work).</emphasis>
200 <IndexTerm><Primary>Creating a Win32 DLL</Primary></IndexTerm>
201 <IndexTerm><Primary>––mk-dll</Primary></IndexTerm>
202 Sealing up your Haskell library inside a DLL is straightforward;
203 compile up the object files that make up the library, and then build
204 the DLL by issuing a command of the form:
209 ghc ––mk-dll -o foo.dll bar.o baz.o wibble.a -lfooble
214 By feeding the ghc compiler driver the option <Option>––mk-dll</Option>, it
215 will build a DLL rather than produce an executable. The DLL will
216 consist of all the object files and archives given on the command
221 To create a `static' DLL, i.e. one that does not depend on the GHC DLLs,
222 use the <Option>-static</Option> when compiling up your Haskell code and
227 A couple of things to notice:
235 Since DLLs correspond to packages (see <XRef LinkEnd="packages">) you need
236 to use <Option>-package-name dll-name</Option> when compiling modules that
237 belong to a DLL if you're going to call them from Haskell. Otherwise, Haskell
238 code that calls entry points in that DLL will do so incorrectly, and crash.
239 For similar reasons, you can only compile a single module tree into a DLL,
240 as <Function>startupHaskell</Function> needs to be able to call its
241 initialisation function, and only takes one such argument (see <XRef
242 LinkEnd="win32-dlls-foreign">). Hence the modules
243 you compile into a DLL must have a common root.
249 By default, the entry points of all the object files will be exported from
250 the DLL when using <Option>––mk-dll</Option>. Should you want to constrain
251 this, you can specify the <Emphasis>module definition file</Emphasis> to use
252 on the command line as follows:
255 ghc ––mk-dll -o .... -optdll--def -optdllMyDef.def
258 See Microsoft documentation for details, but a module definition file
259 simply lists what entry points you want to export. Here's one that's
260 suitable when building a Haskell COM server DLL:
264 DllCanUnloadNow = DllCanUnloadNow@0
265 DllGetClassObject = DllGetClassObject@12
266 DllRegisterServer = DllRegisterServer@0
267 DllUnregisterServer = DllUnregisterServer@0
274 In addition to creating a DLL, the <Option>––mk-dll</Option> option also
275 creates an import library. The import library name is derived from the
276 name of the DLL, as follows:
279 DLL: HScool.dll ==> import lib: libHScool_imp.a
282 The naming scheme may look a bit weird, but it has the purpose of allowing
283 the co-existence of import libraries with ordinary static libraries (e.g.,
284 <Filename>libHSfoo.a</Filename> and
285 <Filename>libHSfoo_imp.a</Filename>.
287 Additionally, when the compiler driver is linking in non-static mode, it
288 will rewrite occurrence of <Option>-lHSfoo</Option> on the command line to
289 <Option>-lHSfoo_imp</Option>. By doing this for you, switching from
290 non-static to static linking is simply a question of adding
291 <Option>-static</Option> to your command line.
301 <Sect2 id="win32-dlls-foreign">
302 <Title>Making DLLs to be called from other languages</Title>
306 If you want to package up Haskell code to be called from other languages,
307 such as Visual Basic or C++, there are some extra things it is useful to
308 know. The dirty details are in the <Emphasis>Foreign Function
309 Interface</Emphasis> definition, but it can be tricky to work out how to
310 combine this with DLL building, so here's an example:
318 Use <Literal>foreign export</Literal> declarations to export the Haskell
319 functions you want to call from the outside. For example,
324 adder :: Int -> Int -> IO Int -- gratuitous use of IO
325 adder x y = return (x+y)
327 foreign export stdcall adder :: Int -> Int -> IO Int
337 ghc -c adder.hs -fglasgow-exts
340 This will produce two files, adder.o and adder_stub.o
346 compile up a <Function>DllMain()</Function> that starts up the Haskell
347 RTS-––a possible implementation is:
350 #include <windows.h>
351 #include <Rts.h>
353 EXTFUN(__stginit_Adder);
355 static char* args[] = { "ghcDll", NULL };
356 /* N.B. argv arrays must end with NULL */
365 if (reason == DLL_PROCESS_ATTACH) {
366 /* By now, the RTS DLL should have been hoisted in, but we need to start it up. */
367 startupHaskell(1, args, __stginit_Adder);
374 Here, <Literal>Adder</Literal> is the name of the root module in the module
375 tree (as mentioned above, there must be a single root module, and hence a
376 single module tree in the DLL).
391 ghc ––mk-dll -o adder.dll adder.o adder_stub.o dllMain.o
399 Start using <Function>adder</Function> from VBA-––here's how I would
400 <Constant>Declare</Constant> it:
403 Private Declare Function adder Lib "adder.dll" Alias "adder@8"
404 (ByVal x As Long, ByVal y As Long) As Long
407 Since this Haskell DLL depends on a couple of the DLLs that come with GHC,
408 make sure that they are in scope/visible.
412 Building statically linked DLLs is the same as in the previous section: it
413 suffices to add <Option>-static</Option> to the commands used to compile up
414 the Haskell source and build the DLL.
427 ;;; Local Variables: ***
429 ;;; sgml-parent-document: ("users_guide.sgml" "book" "chapter") ***