1. 29 Apr, 2011 1 commit
  2. 23 Apr, 2011 7 commits
  3. 22 Apr, 2011 2 commits
  4. 12 Apr, 2011 1 commit
    • Simon Marlow's avatar
      Change the way module initialisation is done (#3252, #4417) · a52ff761
      Simon Marlow authored
      Previously the code generator generated small code fragments labelled
      with __stginit_M for each module M, and these performed whatever
      initialisation was necessary for that module and recursively invoked
      the initialisation functions for imported modules.  This appraoch had
      drawbacks:
      
       - FFI users had to call hs_add_root() to ensure the correct
         initialisation routines were called.  This is a non-standard,
         and ugly, API.
      
       - unless we were using -split-objs, the __stginit dependencies would
         entail linking the whole transitive closure of modules imported,
         whether they were actually used or not.  In an extreme case (#4387,
         #4417), a module from GHC might be imported for use in Template
         Haskell or an annotation, and that would force the whole of GHC to
         be needlessly linked into the final executable.
      
      So now instead we do our initialisation with C functions marked with
      __attribute__((constructor)), which are automatically invoked at
      program startup time (or DSO load-time).  The C initialisers are
      emitted into the stub.c file.  This means that every time we compile
      with -prof or -hpc, we now get a stub file, but thanks to #3687 that
      is now invisible to the user.
      
      There are some refactorings in the RTS (particularly for HPC) to
      handle the fact that initialisers now get run earlier than they did
      before.
      
      The __stginit symbols are still generated, and the hs_add_root()
      function still exists (but does nothing), for backwards compatibility.
      a52ff761
  5. 11 Apr, 2011 1 commit
  6. 08 Apr, 2011 1 commit
  7. 04 Apr, 2011 1 commit
  8. 26 Mar, 2011 1 commit
  9. 23 Mar, 2011 1 commit
  10. 25 Feb, 2011 1 commit
  11. 19 Feb, 2011 1 commit
  12. 10 Feb, 2011 1 commit
  13. 24 Jan, 2011 1 commit
  14. 13 Jan, 2011 1 commit
  15. 16 Jan, 2011 1 commit
  16. 15 Jan, 2011 1 commit
    • Ian Lynagh's avatar
      Build system improvements · a3be88fd
      Ian Lynagh authored
      We no longer use dummy-ghc; instead we don't configure most packages
      until the stage1 compiler is available.
        
      We also now use Cabal for building the ghc-bin package.
      
      There are a couple more sanity checks too.
      a3be88fd
  17. 31 Dec, 2010 1 commit
  18. 19 Dec, 2010 1 commit
    • kili's avatar
      Drop GhcWithLlvmCodeGen configuration bits · 17ff3689
      kili authored
      The LLVM code generator is always built unconditionally, so both the
      configuration variable in mk/config.mk.in as well as the string in
      compilerInfo can be removed.
      17ff3689
  19. 17 Dec, 2010 1 commit
  20. 14 Dec, 2010 2 commits
  21. 07 Dec, 2010 1 commit
    • Ian Lynagh's avatar
      Make CPPFLAGS variables, as well as CFLAGS and LDFLAGS · 75cd9c50
      Ian Lynagh authored
      This fixes the "does unsetenv return void" test in the unix package on
      OS X, if I tell it to make 10.4-compatible binaries. The test uses
      CPPFLAGS but not CFLAGS, so it thought it returned int (as it was
      in 10.5-mode), but the C compiler (using CFLAGS, so in 10.4 mode)
      thought it returned void.
      
      I also added CONF_LD_OPTS_STAGE$3 to the list of things in LDFLAGS,
      which looks like an accidental ommission.
      75cd9c50
  22. 27 Nov, 2010 1 commit
  23. 24 Nov, 2010 3 commits
  24. 23 Nov, 2010 1 commit
  25. 20 Sep, 2010 2 commits
  26. 18 Sep, 2010 1 commit
  27. 04 Sep, 2010 1 commit
  28. 29 Aug, 2010 1 commit
    • Sergei Trofimovich's avatar
      ppc: switch handling of 'foreign import wrapper' (FIW) to libffi · 33653031
      Sergei Trofimovich authored
      Joseph Jezak reported darcs-2.4.4 SIGSEGV in interactive mode in ghc-6.12.3.
      So I've concluded ppc also has rotten native adjustor. I don't have hardware
      to verify the patch (ticket #3516 should help to test it), but I think it will
      help (as similar patch helped for ia64 and ppc64).
      33653031
  29. 19 Aug, 2010 1 commit