Changes between Version 7 and Version 8 of Building/PlatformsScriptsFileNames


Ignore:
Timestamp:
Mar 31, 2009 8:33:44 AM (5 years ago)
Author:
simonmar
Comment:

remove

Legend:

Unmodified
Added
Removed
Modified
  • Building/PlatformsScriptsFileNames

    v7 v8  
    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. 
     1This page is obsolete.  Please redirect links to [wiki:Building/Platforms/Windows], or another appropriate place.