1. 24 Sep, 2009 1 commit
  2. 17 Sep, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix build on Mac OS 10.6 (Snow Leopard) · c2cd83e7
      chak@cse.unsw.edu.au. authored
      - We have -m32 as machine-dependent option for gcc for a 32 bit build
      - Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
        stack smashing checks inserted by gcc by default on this platform.
      c2cd83e7
  3. 18 Jul, 2009 1 commit
  4. 14 Jul, 2009 1 commit
  5. 06 Jul, 2009 1 commit
  6. 01 Jul, 2009 1 commit
  7. 10 Jun, 2009 1 commit
  8. 19 May, 2009 1 commit
  9. 15 May, 2009 2 commits
    • Duncan Coutts's avatar
      Set the soname when creating a shared lib · 6efacfe8
      Duncan Coutts authored
      It's still possible to override it, just use -optl-Wl,-soname, eg:
      ghc -shared -dynamic foo.o -o libfoo.so -optl-Wl,-soname,libbar.so
      6efacfe8
    • Duncan Coutts's avatar
      Keep C main separate from rts lib and link it in for standalone progs · fa00cc50
      Duncan Coutts authored
      Previously the object code for the C main function lived in the rts
      lib, however this is a problem when the rts is built as a shared lib.
      With Windows DLLs it always causes problems while on ELF systems it's a
      problem when the user decides to use their own C main function rather
      than a Haskell Main.main. So instead we now put main in it's own tiny
      little static lib libHSrtsmain.a which we install next to the rts libs.
      Whenever ghc links a program (without -no-hs-main) then it also links
      in -lHSrtsmain. For consistency we always do it this way now rather
      than trying to do it differently for static vs shared libraries.
      fa00cc50
  10. 14 May, 2009 1 commit
    • Duncan Coutts's avatar
      Remove old Windows-only implementation of keeping main outside the rts · 3d411991
      Duncan Coutts authored
      We now do it for all ways and for all platforms. This was a Windows-only
      version that only kept a separate Main.dyn_o for the dynamic linking case.
      It had to do that because Windows DLLs are stricter about unresolved symbols
      where as for ELF platforms we only run into the problem when we're not using
      a Haskell main function.
      3d411991
  11. 20 May, 2009 1 commit
  12. 13 May, 2009 1 commit
  13. 22 Apr, 2009 1 commit
  14. 16 Mar, 2009 1 commit
  15. 05 Mar, 2009 2 commits
  16. 11 Feb, 2009 1 commit
  17. 11 Dec, 2008 1 commit
  18. 30 Nov, 2008 1 commit
  19. 28 Nov, 2008 2 commits
  20. 25 Nov, 2008 1 commit
    • Thomas Schilling's avatar
      Major clean-up of HscMain. · e06951a7
      Thomas Schilling authored
      This patch entails a major restructuring of HscMain and a small bugfix
      to MkIface (which required the restructuring in HscMain).
      
      In MkIface:
      
        - mkIface* no longer outputs orphan warnings directly and also no
          longer quits GHC when -Werror is set.  Instead, errors are
          reported using the common IO (Messages, Maybe result) scheme.
      
      In HscMain:
      
        - Get rid of the 'Comp' monad.  This monad was mostly GhcMonad + two
          reader arguments, a ModSummary for the currently compiled module
          and a possible old interface.  The latter actually lead to a small
          space-leak since only its hash was needed (to check whether the
          newly-generated interface file was the same as the original one).
      
          Functions originally of type 'Comp' now only take the arguments
          that they actually need.  This leads to slighly longer argument
          lists in some places, however, it is now much easier to see what
          is actually going on.
      
        - Get rid of 'myParseModule'.  Rename 'parseFile' to 'hscParse'.
      
        - Join 'deSugarModule' and 'hscDesugar' (keeping the latter).
      
        - Rename 'typecheck{Rename}Module{'}' to 'hscTypecheck{Rename}'.
          One variant keeps the renamed syntax, the other doesn't.
      
        - Parameterise 'HscStatus', so that 'InteractiveStatus' is just a
          different parameterisation of 'HscStatus'.
      
        - 'hscCompile{OneShot,Batch,Nothing,Interactive}' are now
          implemented using a (local) typeclass called 'HsCompiler'.  The
          idea is to make the common structure more obvious.  Using this
          typeclass we now have two functions 'genericHscCompile' (original
          'hscCompiler') and 'genericHscRecompile' (original 'genComp')
          describing the default pipeline.  The methods of the typeclass
          describe a sort of "hook" interface (in OO-terms this would be
          called the "template method" pattern).
      
          One problem with this approach is that we parameterise over the
          /result/ type which, in fact, is not actually different for
          "nothing" and "batch" mode.  To avoid functional dependencies or
          associated types, we use type tags to make them artificially
          different and parameterise the type class over the result type.
          A perhaps better approach might be to use records instead.
          
        - Drop some redundant 'HscEnv' arguments.  These were likely
          different from what 'getSession' would return because during
          compilation we temporarily set the module's DynFlags as well as a
          few other fields.  We now use the 'withTempSession' combinator to
          temporarily change the 'HscEnv' and automatically restore the
          original session after the enclosed action has returned (even in
          case of exceptions).
      
        - Rename 'hscCompile' to 'hscGenHardCode' (since that is what it
          does).
      
      Calls in 'GHC' and 'DriverPipeline' accordingly needed small
      adaptions.
      e06951a7
  21. 22 Nov, 2008 1 commit
  22. 21 Nov, 2008 1 commit
  23. 07 Nov, 2008 1 commit
  24. 13 Oct, 2008 1 commit
  25. 07 Oct, 2008 1 commit
  26. 23 Sep, 2008 1 commit
  27. 14 Sep, 2008 1 commit
  28. 01 Sep, 2008 1 commit
    • Simon Marlow's avatar
      Check the modification times of libraries in --make link step · 880a6b90
      Simon Marlow authored
      When linking in --make we check the modification time of the
      executable against the modification time of the object files, and only
      re-link if any object file is newer.  However, we should also check
      the modification times of packages, since the recompilation checker
      also tracks dependencies in packages.  
      
      In a GHC build this means that if you recompile stage2 and don't
      manage to change any fingerpints, we won't recompile Main but we'll
      still re-link it.
      880a6b90
  29. 26 Aug, 2008 1 commit
  30. 21 Aug, 2008 1 commit
    • Simon Marlow's avatar
      Don't use the cc-options from packages when compiling .hc files · 39271273
      Simon Marlow authored
      Now that we don't include any header files in .hc apart from our own,
      the cc-options from packages are at best superfluous, so don't pass
      them.
      
      We still pass them to .c compilations, although I've just made changes
      to Cabal so that cc-options from a .cabal file are not copied into the
      InstalledPackageInfo.  Most uses of cc-options in Cabal are clearly
      intended to be local to the package, but they were being propagated
      everywhere, almost certainly unintentionally.
      
      The way is left open for Cabal to allow packages to specify cc-options
      that get propagated in the future, if we find a use case for this.
      39271273
  31. 31 Jul, 2008 1 commit
  32. 30 Jul, 2008 1 commit
  33. 24 Jul, 2008 1 commit
  34. 11 Jul, 2008 1 commit
  35. 08 Jul, 2008 1 commit
  36. 05 Jul, 2008 1 commit
  37. 20 Jun, 2008 1 commit