Changes between Version 19 and Version 20 of CrossCompilation


Ignore:
Timestamp:
Jan 1, 2012 10:58:58 PM (2 years ago)
Author:
heisenbug
Comment:

update status on pending patches

Legend:

Unmodified
Added
Removed
Modified
  • CrossCompilation

    v19 v20  
    7878Autoconf offers only limited support for cross compiling. While it professes to know about three platforms, base, host, and target; it knows only about one tool-chain. It uses that tool-chain to determine two classes of information: Information about how to use the tool-chain itself, and information about the target of that tool-chain. Hence, in the cross-compilation case, it makes sense for ./configure to be told about XT. 
    7979 
    80 Autoconf's concept and variable $cross_compiling only gets set if B ≠ H. This is correct from the standpoint of compiling a simple program (for which T is irrelevant). In our normalized version of B/H/T, B = H, so the logic of autoconf needs to be amended ''(patch pending)''. 
     80Autoconf's concept and variable $cross_compiling only gets set if B ≠ H. This is correct from the standpoint of compiling a simple program (for which T is irrelevant). In our normalized version of B/H/T, B = H, so the logic of autoconf needs to be amended. 
    8181 
    8282This leaves us with the issue of how to tell it about parts of HT it can't infer from the stage0 compiler. We need a new set of variables that are how to compile, link and run things on the host, which if cross compiling need to be different. There needs to be some way to pass those on the configure line. Perhaps something like: 
     
    9090}}} 
    9191 
    92 A tricky aspect is that some properities of the tool chain are probed by Autoconf ("is cc gcc?", "does ar need ranlib?"). These probes technically should be performed for each tool-chain. ''(partial patch pending)'' 
     92A tricky aspect is that some properities of the tool chain are probed by Autoconf ("is cc gcc?", "does ar need ranlib?"). These probes technically should be performed for each tool-chain. 
    9393 
    9494 
    9595Both ./configure, cabal configure, and hsc2hs desire to run things built for T. If the XT contains an emulator, than this is possible. Two approaches need to be supported here: 
    96  1. Autoconf can now descern many values without running code and configure.ac / aclocal.m4 scripts can be changed to avoid running in many cases. (For example in libraries/base I rewrote things to use AC_COMPUTE_INT rather than AC_RUN_IFELSE to find the sizes of htypes.)  ''(patch pending)'' 
     96 1. Autoconf can now descern many values without running code and configure.ac / aclocal.m4 scripts can be changed to avoid running in many cases. (For example in libraries/base I rewrote things to use AC_COMPUTE_INT rather than AC_RUN_IFELSE to find the sizes of htypes.) 
    9797 2. Plumb the need to call the emulator to run in the right places. An alternative is to use an alternate linker command that inserts the emulator into those build executables (but this is tricky as you don't want to use that link when building for the real target...) 
    9898 
     
    101101The overall build sequencing needs to recognize the cross compilation configuration, and adjust build targets and final packaging to match. 
    102102 
    103 There are few other places where the make system needs to get fixed up to use the correct tool-chain at the right time ''(partial patche pending)''. 
     103There are few other places where the make system needs to get fixed up to use the correct tool-chain at the right time. 
    104104 
    105105There are a set of CPP symbols that are defined when compiling both Haskell and C code: 
     
    125125In general, the problems have all been in plumbing the concepts of XT vs. HT around the build system. While I've been able to fudge it for most of the components though there are places where my work around is forced. 
    126126 
     127===  Jan 2012: Gabor Greif === 
     128Looks like Marks has submitted patches and 
     129[http://www.haskell.org/pipermail/cvs-ghc/2011-April/061685.html they have been integrated by Ian] 
     130into the main repository. This means GHC v7.4.1 *should* be ready for the procedures outlined above. 
     131 
     132I am about to test whether the theory matches practice and report back here. 
     133 
    127134----- 
    128135== Questions == 
     
    130137===  Jan 2012: Gabor Greif === 
    131138 * The [wiki:Building/Architecture/Idiom/Stages build stages] page says that Template Haskell is disabled in stage1 compilers. This would mean that a cross-compiler is devoid of an important feature. Any tweak possible to fix this? 
    132  * Did any of the TODOs and pending patches make it into the GHC 7.4/HEAD repositories? 
     139 
    133140