From 57ff175ec6b215daba92cf1cb6ac1b35b063768c Mon Sep 17 00:00:00 2001 From: rrt Date: Tue, 27 Jun 2000 10:08:48 +0000 Subject: [PATCH] [project @ 2000-06-27 10:08:48 by rrt] Replace documentation for dll_Ifs.hi with a note about using -package-name. Please merge. --- ghc/docs/users_guide/win32-dlls.sgml | 69 +++++----------------------------- 1 file changed, 9 insertions(+), 60 deletions(-) diff --git a/ghc/docs/users_guide/win32-dlls.sgml b/ghc/docs/users_guide/win32-dlls.sgml index 672f7ac..ce1cbff 100644 --- a/ghc/docs/users_guide/win32-dlls.sgml +++ b/ghc/docs/users_guide/win32-dlls.sgml @@ -40,12 +40,11 @@ sh$ -will give you a binary as before, but the main.exe generated -will use the Prelude and RTS DLLs instead. +will give you a binary as before, but the main.exe generated will use the Prelude and RTS DLLs instead. -6K for a "hello, world" application - not bad, huh? :-) +6K for a "hello, world" application---not bad, huh? :-) @@ -82,7 +81,7 @@ the DLL by issuing the following command: -sh$ ghc --mk-dll -o HSsuper.dll A.o Super.o B.o libmine.a -lgdi32 +ghc --mk-dll -o HSsuper.dll A.o Super.o B.o libmine.a -lgdi32 @@ -103,56 +102,11 @@ A couple of things to notice: -When compiling the module A, the code emitted by the compiler -differs depending on whether or not the functions and data it is -importing from other Haskell modules correspond to symbols that are -packaged up in a ghc-compiled DLL. To resolve whether such imports are -'DLL imports' or not, the following rules are used: - - - - - -If the compiler imports from a module that's in the same directory as -the one being compiled, it is assumed to not belong to a different DLL -(or executable) than the module being processed, so none of the -same-directory imports are considered 'DLL imports'. - - - - - - -If a directory contains the (probably empty) file -dLL_ifs.hi, the code corresponding to the interface -files found in that directory are assumed to live in a DLL -separate from the one being compiled. - -Notice that the first rule takes precedence over this one, so if -you're compiling a module that imports from a Haskell module whose -interface file live in the same directory, and that directory -also contains the file dLL_ifs.hi, the import is still not -being considered to be a 'DLL import'. - - - - - - -If compiling with the option , the previous rule -is disabled. - - - - - - -So, in short, after having built your Haskell DLL, make sure you -create the file dLL_ifs.hi in the directory that contains -its interface files. If you don't, Haskell code that calls upon entry -points in that DLL, will do so incorrectly, and a crash will result. -(it is unfortunate that this isn't currently caught at compile-time). +Since DLLs correspond to packages (see ) you need +to use when compiling modules that +belong to a DLL. If you don't, Haskell code that calls entry points in that +DLL will do so incorrectly, and a crash will result. @@ -160,21 +114,16 @@ points in that DLL, will do so incorrectly, and a crash will result. By default, the entry points of all the object files will -be exported from the DLL when using . Should you want -to constrain this, you can specify the module definition file -to use on the command line as follows: - +be exported from the DLL when using . Should you want to constrain this, you can specify the module definition file to use on the command line as follows: -sh$ ghc --mk-dll -o .... -optdll--def -optdllMyDef.def +ghc --mk-dll -o .... -optdll--def -optdllMyDef.def - See Microsoft documentation for details, but a module definition file simply lists what entry points you want to export. Here's one that's suitable when building a Haskell COM server DLL: - EXPORTS DllCanUnloadNow = DllCanUnloadNow@0 -- 1.7.10.4