| 1 | | |
| 2 | | |
| 3 | | = Platforms, scripts, and file names = |
| 4 | | |
| 5 | | GHC is designed both to be built, and to run, on both Unix and Windows. This flexibility |
| 6 | | gives rise to a good deal of brain-bending detail, which we have tried to collect in this chapter. |
| 7 | | |
| 8 | | |
| 9 | | == Windows platforms: Cygwin, MSYS, and MinGW == |
| 10 | | |
| 11 | | The build system is built around Unix-y makefiles. Because it's not native, |
| 12 | | the Windows situation for building GHC is particularly confusing. This section |
| 13 | | tries to clarify, and to establish terminology. |
| 14 | | |
| 15 | | === MinGW === |
| 16 | | |
| 17 | | [http://www.mingw.org MinGW (Minimalist GNU for Windows)] |
| 18 | | is a collection of header |
| 19 | | files and import libraries that allow one to use {{{gcc}}} and produce |
| 20 | | native Win32 programs that do not rely on any third-party DLLs. The |
| 21 | | current set of tools include GNU Compiler Collection ({{{gcc}}}), GNU Binary |
| 22 | | Utilities (Binutils), GNU debugger (Gdb), GNU make, and assorted |
| 23 | | other utilities. |
| 24 | | |
| 25 | | GHC requires both the MinGW "core system" (a C compiler + other essential stuff) |
| 26 | | and the g++ system (required by libffi) to be installed. |
| 27 | | |
| 28 | | The down-side of MinGW is that the MinGW libraries do not support anything like the full |
| 29 | | Posix interface. |
| 30 | | |
| 31 | | === Cygwin and MSYS === |
| 32 | | |
| 33 | | You can't use the MinGW to ''build'' GHC, because MinGW doesn't have a shell, |
| 34 | | or the standard Unix commands such as {{{mv}}}, {{{rm}}}, |
| 35 | | {{{ls}}}, nor build-system stuff such as {{{make}}} and {{{darcs}}}. |
| 36 | | For that, there are two choices: [http://www.cygwin.com Cygwin] |
| 37 | | and [http://www.mingw.org/msys.shtml MSYS]: |
| 38 | | * Cygwin comes with compilation tools ({{{gcc}}}, {{{ld}}} and so on), which |
| 39 | | compile code that has access to all of Posix. The price is that the executables must be |
| 40 | | dynamically linked with the Cygwin DLL, so that ''you cannot run a Cywin-compiled program on a machine |
| 41 | | that doesn't have Cygwin''. Worse, Cygwin is a moving target. The name of the main DLL, {{{cygwin1.dll}}} |
| 42 | | does not change, but the implementation certainly does. Even the interfaces to functions |
| 43 | | it exports seem to change occasionally. |
| 44 | | [[br]] |
| 45 | | * MSYS is a fork of the Cygwin tree, so they |
| 46 | | are fundamentally similar. However, MSYS is by design much smaller and simpler. |
| 47 | | Access to the file system goes |
| 48 | | through fewer layers, so MSYS is quite a bit faster too. |
| 49 | | [[br]] |
| 50 | | Furthermore, MSYS provides no compilation tools; it relies instead on the MinGW tools. These |
| 51 | | compile binaries that run with no DLL support, on any Win32 system. |
| 52 | | However, MSYS does come with all the make-system tools, such as {{{make}}}, {{{autoconf}}}, |
| 53 | | {{{darcs}}}, {{{ssh}}} etc. To get these, you have to download the |
| 54 | | MsysDTK (Developer Tool Kit) package, as well as the base MSYS package. |
| 55 | | [[br]] |
| 56 | | MSYS does have a DLL, but it's only used by MSYS commands ({{{sh}}}, {{{rm}}}, |
| 57 | | {{{ssh}}} and so on), |
| 58 | | not by programs compiled under MSYS. |
| 59 | | |
| 60 | | === Targeting MinGW === |
| 61 | | |
| 62 | | We want GHC to compile programs that work on any Win32 system. Hence: |
| 63 | | * GHC does invoke a C compiler, assembler, linker and so on, but we ensure that it only |
| 64 | | invokes the MinGW tools, not the Cygwin ones. That means that the programs GHC compiles |
| 65 | | will work on any system, but it also means that the programs GHC compiles do not have access |
| 66 | | to all of Posix. In particular, they cannot import the (Haskell) Posix |
| 67 | | library; they have to do |
| 68 | | their input output using standard Haskell I/O libraries, or native Win32 bindings. |
| 69 | | We will call a GHC that targets MinGW in this way ''GHC-mingw''. |
| 70 | | * To make the GHC distribution self-contained, the GHC distribution includes the MinGW {{{gcc}}}, |
| 71 | | {{{as}}}, {{{ld}}}, and a bunch of input/output libraries. |
| 72 | | |
| 73 | | So ''GHC targets MinGW'', not Cygwin. |
| 74 | | It is in principle possible to build a version of GHC, ''GHC-cygwin'', |
| 75 | | that targets Cygwin instead. The up-side of GHC-cygwin is |
| 76 | | that Haskell programs compiled by GHC-cygwin can import the (Haskell) Posix library. |
| 77 | | ''We do not support GHC-cygwin, however; it is beyond our resources.'' |
| 78 | | |
| 79 | | |
| 80 | | While GHC ''targets'' MinGW, that says nothing about |
| 81 | | how GHC is ''built''. We use both MSYS and Cygwin as build environments for |
| 82 | | GHC; both work fine, though MSYS is rather lighter weight. |
| 83 | | |
| 84 | | In your build tree, the compiler you build uses the {{{gcc}}} that you specify using the |
| 85 | | {{{--with-gcc}}} flag when you run {{{configure}}} (see below). |
| 86 | | The makefiles are careful to use the right gcc, either via the in-place ghc or directly, |
| 87 | | to compile any C files, so that we use correct {{{gcc}}} rather than |
| 88 | | whatever one happens to be in your path. However, the makefiles do use whatever {{{ld}}} |
| 89 | | and {{{ar}}} happen to be in your path. This is a bit naughty, but (a) they are only |
| 90 | | used to glom together .o files into a bigger .o file, or a .a file, |
| 91 | | so they don't ever get libraries (which would be bogus; they might be the wrong libraries), and (b) |
| 92 | | Cygwin and MinGW use the same .o file format. So its ok. |
| 93 | | |
| 94 | | === File names === |
| 95 | | |
| 96 | | Cygwin, MSYS, and the underlying Windows file system all understand file paths of form {{{c:/tmp/foo}}}. |
| 97 | | However: |
| 98 | | * MSYS programs understand {{{/bin}}}, {{{/usr/bin}}}, and map Windows's lettered drives as |
| 99 | | {{{/c/tmp/foo}}} etc. The exact mount table is given in the doc subdirectory of the MSYS distribution. |
| 100 | | [[br]] |
| 101 | | When it invokes a command, the MSYS shell sees whether the invoked binary lives in the MSYS {{{/bin}}} |
| 102 | | directory. If so, it just invokes it. If not, it assumes the program is no an MSYS program, and walks over the command-line |
| 103 | | arguments changing MSYS paths into native-compatible paths. |
| 104 | | It does this inside sub-arguments and inside quotes. For example, |
| 105 | | if you invoke |
| 106 | | {{{ |
| 107 | | foogle -B/c/tmp/baz |
| 108 | | }}} |
| 109 | | the MSYS shell will actually call {{{foogle}}} with argument {{{-Bc:/tmp/baz}}}. |
| 110 | | * Cygwin programs have a more complicated mount table, and map the lettered drives as {{{/cygdrive/c/tmp/foo}}}. |
| 111 | | [[br]] |
| 112 | | The Cygwin shell does no argument processing when invoking non-Cygwin programs. |
| 113 | | |
| 114 | | |
| 115 | | === Host System vs Target System === |
| 116 | | |
| 117 | | |
| 118 | | In the source code you'll find various ifdefs looking like: |
| 119 | | {{{ |
| 120 | | #ifdef mingw32_HOST_OS |
| 121 | | ...blah blah... |
| 122 | | #endif |
| 123 | | }}} |
| 124 | | and |
| 125 | | {{{ |
| 126 | | #ifdef mingw32_TARGET_OS |
| 127 | | ...blah blah... |
| 128 | | #endif |
| 129 | | }}} |
| 130 | | These macros are set by the configure script (via the file config.h). |
| 131 | | Which is which? The criterion is this. In the ifdefs in GHC's source code: |
| 132 | | * The "host" system is the one on which GHC itself will be run. |
| 133 | | * The "target" system is the one for which the program compiled by GHC will be run. |
| 134 | | For a stage-2 compiler, in which GHCi is available, the "host" and "target" systems must be the same. |
| 135 | | So then it doesn't really matter whether you use the HOST_OS or TARGET_OS cpp macros. |
| 136 | | |
| 137 | | |
| 138 | | == Wrapper scripts == |
| 139 | | |
| 140 | | |
| 141 | | Many programs, including GHC itself and hsc2hs, need to find associated binaries and libraries. |
| 142 | | For ''installed'' programs, the strategy depends on the platform. We'll use |
| 143 | | GHC itself as an example: |
| 144 | | * On Unix, the command {{{ghc}}} is a shell script, generated by Cabal from `ghc/ghc.wrapper`, |
| 145 | | that invokes the real binary, passing "-B''path''" as an argument to tell {{{ghc}}} |
| 146 | | where to find its supporting files. |
| 147 | | * On vanilla Windows, it turns out to be much harder to make reliable script to be run by the |
| 148 | | native Windows shell {{{cmd}}} (e.g. limits on the length |
| 149 | | of the command line). So instead we invoke the GHC binary directly, with no -B flag. |
| 150 | | GHC uses the Windows {{{getExecDir}}} function to find where the executable is, |
| 151 | | and from that figures out where the supporting files are. |
| 152 | | (You can find the layout of GHC's supporting files in the |
| 153 | | section "Layout of installed files" of Section 2 of the GHC user guide.) |
| 154 | | |
| 155 | | |
| 156 | | Things work differently for ''in-place'' execution, where you want to |
| 157 | | execute a program that has just been built in a build tree. The difference is that the |
| 158 | | layout of the supporting files is different. |
| 159 | | In this case, whether on Windows or Unix, we always use a shell script. This works OK |
| 160 | | on Windows because the script is executed by MSYS or Cygwin, which don't have the |
| 161 | | shortcomings of the native Windows {{{cmd}}} shell. |
| | 1 | This page is obsolete. Please redirect links to [wiki:Building/Platforms/Windows], or another appropriate place. |
