1. 04 Aug, 2014 1 commit
    • Sergei Trofimovich's avatar
      Use 'install' command for 'inplace/' install as we do in 'make install' · 637978fa
      Sergei Trofimovich authored
      Summary:
      On hardened gentoo ghc-stage2 does not work as-is,
      as it uses runtime code generation/loading, thus
      ghc0stage2 needs to be marked in a special way
      (via POSIX extened attributes).
      
      Before the patch we used 'cp -p' command, which
      does not preserve that marking. It leads to buid
      failure on hardened. Hardened's 'install' does
      preserve POSIX xattrs, thus patch uses it instead.
      
      'inplace/' directory can be seen the same way as target
      for 'make install', thus using the same facilities
      to install files to 'inplace/' sounds more consistent.
      
      Reported-by: Jay Yang
      Gentoo-bug: https://bugs.gentoo.org/518734
      
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: tested ghc installation on vanilla and hardened distributions
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D108
      637978fa
  2. 27 Mar, 2014 1 commit
    • Simon Marlow's avatar
      Include EXTRA_LD_OPTS (amongst other things) when linking programs · 975e9cb8
      Simon Marlow authored
      One problem was that we weren't including $1_$2_DIST_LD_OPTS when
      linking a program, which looks to be accidental: it was being defined
      but not used anywhere.  This meant that setting $1_$2_EXTRA_LD_OPTS,
      for example, had no effect.
      
      This commit straightens out the handling of LD_OPTS to be consistent
      with the way we handle CC_OPTS and HC_OPTS.
      975e9cb8
  3. 28 Jan, 2014 1 commit
  4. 22 Nov, 2013 1 commit
  5. 25 Oct, 2013 1 commit
  6. 01 Oct, 2013 1 commit
  7. 22 Jun, 2013 2 commits
  8. 16 May, 2013 2 commits
  9. 14 May, 2013 1 commit
  10. 12 May, 2013 1 commit
    • Ian Lynagh's avatar
      More work towards dynamic programs on Windows · b35a6ce0
      Ian Lynagh authored
      Dynamic GHC is now working in-place, but pathologically slow due
      to the DLL split.
      
      (GHC assumes that all intra-package calls are in the same DLL, but that
      isn't true when we split the GHC package into 2 DLLs. That means that
      GHC's startup time is around 22 seconds, as it is doing run-time
      linking).
      
      Also, ghci isn't actually working yet:
      
      $ inplace/bin/ghc-stage2 --interactive
      GHCi, version 7.7.20130512: http://www.haskell.org/ghc/  :? for help
      Loading package ghc-prim ... <command line>: can't load .so/.DLL for:
      HSghc-prim-0.3.1.0.dll (addDLL: could not load DLL)
      ghc-stage2.exe: HSghc-prim-0.3.1.0: The specified module could not be
      found.
      b35a6ce0
  11. 21 Apr, 2013 1 commit
  12. 20 Apr, 2013 2 commits
  13. 19 Mar, 2013 1 commit
  14. 15 Mar, 2013 2 commits
  15. 03 Mar, 2013 2 commits
  16. 01 Mar, 2013 1 commit
  17. 22 Feb, 2013 1 commit
  18. 21 Feb, 2013 3 commits
  19. 17 Feb, 2013 1 commit
  20. 16 Feb, 2013 1 commit
  21. 05 Feb, 2013 1 commit
    • ian@well-typed.com's avatar
      Add a dependency of program modules on GHC.TopHandler · 40e43fa2
      ian@well-typed.com authored
      If you were unlucky, the build could fail, e.g.:
      
      utils\mkUserGuidePart\Main.hs:1:1:
          Failed to load interface for `GHC.TopHandler'
          There are files missing in the `base' package,
          try running 'ghc-pkg check'.
          Use -v to see a list of the files searched for.
      utils/mkUserGuidePart/ghc.mk:18: recipe for target `utils/mkUserGuidePart/dist/build/Main.o' failed
      40e43fa2
  22. 11 Jan, 2013 1 commit
  23. 08 Nov, 2012 1 commit
  24. 22 Oct, 2012 1 commit
  25. 14 Oct, 2012 3 commits
  26. 04 Oct, 2012 1 commit
  27. 03 Oct, 2012 1 commit
    • ian@well-typed.com's avatar
      Build the dynamic way by default on Linux/amd64 · 898cb090
      ian@well-typed.com authored
      This required various build system changes to get the build to go
      through.
      
      In the inplace shell wrappers, we set LD_LIBRARY_PATH to allow programs
      to find their libraries. In the future, we might change the inplace tree
      to be the same shape as an installed tree instead. However, this would
      mean changing the way we do installation, as currently we use cabal's
      installation methods to install the libraries, but that only works if
      the libraries are under libraries/foo/dist-install/build/..., rather
      than in inplace/lib/...
      898cb090
  28. 01 Oct, 2012 2 commits
  29. 27 Sep, 2012 2 commits