1. 22 Dec, 2014 1 commit
  2. 27 Nov, 2014 1 commit
    • Herbert Valerio Riedel's avatar
      Embed Git commit id into `ghc --info` output · 73e5e2f8
      Herbert Valerio Riedel authored
      Since we switched to a Git submodule based GHC Git repo, `ghc.git`'s
      commit id uniquely identifies the state of the GHC source-tree. So
      having that information embedded into the `ghc` executable provides
      valuable information to track accurately (especially when created by
      buildbots) from which source-tree-state a given `ghc` snapshot
      (distribution) was generated.
      
      So this commit adds a new field `"Project Git commit id"` to the
      `ghc --info` meta-data containing the `./configure`-time Git commit id
      as reported by `git rev-parse HEAD`.
      
      This field can also be queried with `ghc --print-project-git-commit-id`.
      
      For source distributions, the file `GIT_COMMIT_ID` is created (with some
      sanity checking to detect stale commit ids, as that would render this
      information rather useless)
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D528
      73e5e2f8
  3. 26 Nov, 2014 1 commit
  4. 19 Nov, 2014 1 commit
  5. 14 Oct, 2014 1 commit
  6. 07 Oct, 2014 1 commit
    • Yuras's avatar
      Fix configure check for 9439 bug · 1ec91133
      Yuras authored
      Summary: We should escape path to ghc.On wondows usually ghc comes from HP, which is installed somewhere in "...\Haskell Platform\..." Note space in the middle.
      
      Test Plan: not necessary
      
      Reviewers: rwbarton, hvr, austin
      
      Reviewed By: rwbarton, hvr, austin
      
      Subscribers: rwbarton, simonmar, ezyang, carter, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D304
      1ec91133
  7. 05 Oct, 2014 1 commit
    • Sergei Trofimovich's avatar
      rts: unrust 'libbfd' debug symbols parser · cb0a503a
      Sergei Trofimovich authored
      
      
      Summary:
      Patch does the following:
      - fixes detection of working libbfd on modern linux
        platforms (where bfd_uncompress_section_contents is a macro)
      - disables 'bfd' by default and adds '--enable-bfd-debug'
        configure option. As bfd's ABI is unstable
        the feature is primarily useful by ghc hackers.
      
      Not done (subject for another patch):
      - one-time bfd object memory leak in DEBUG_LoadSymbols
      - in '-dynamic' mode debugging symbols are loaded only for
        current executable, not all libraries it is linked against.
      
      Fixes Issue #8790
      Signed-off-by: default avatarSergei Trofimovich <slyfox@gentoo.org>
      
      Test Plan: built unregisterised ghc on amd64 and ran './hello +RTS -Di' there
      
      Reviewers: simonmar, austin
      
      Reviewed By: simonmar, austin
      
      Subscribers: thomie, simonmar, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D193
      
      GHC Trac Issues: #8790
      cb0a503a
  8. 02 Sep, 2014 1 commit
  9. 19 Aug, 2014 2 commits
  10. 17 Aug, 2014 1 commit
    • kgardas's avatar
      workaround Solaris 11 GNU C CPP issue by using GNU C 3.4 as CPP · 2d42564a
      kgardas authored
      Summary:
      Solaris 11 distributed GNU C 4.5.x is configured in a way that its
      CPP is not working well while invoked from GHC. GHC runs it with
      -x assembler-with-cpp and in this particular configuration GNU C CPP
      does not provide any line-markers so GHC's output of errors or warnings
      is confusing since it points to preprocessed file in /tmp and not
      to the original Haskell file. Fortunately old GNU C 3.4.x is still
      provided by the OS and when installed it'll be used automatically
      as GHC CPP which is whole logic of this patch. So although we use modern
      GCC as a C compiler and assembler we use old GCC as a C preprocessor.
      
      Test Plan: validate
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: phaskell, simonmar, relrod, ezyang, carter
      
      Differential Revision: https://phabricator.haskell.org/D151
      2d42564a
  11. 13 Aug, 2014 1 commit
  12. 09 Aug, 2014 1 commit
  13. 05 Aug, 2014 1 commit
  14. 04 Jul, 2014 1 commit
  15. 02 Jul, 2014 1 commit
  16. 27 Mar, 2014 2 commits
  17. 23 Mar, 2014 2 commits
  18. 07 Feb, 2014 1 commit
  19. 29 Jan, 2014 1 commit
  20. 28 Jan, 2014 1 commit
  21. 01 Oct, 2013 1 commit
  22. 29 Sep, 2013 1 commit
  23. 04 Sep, 2013 1 commit
    • thoughtpolice's avatar
      Make sure -fcmm-sink is passed to Parser properly · 9e133b9d
      thoughtpolice authored
      
      
      Parser.hs needs to be compiled with -fcmm-sink on x86 platforms, so the
      register allocator doesn't run out of stack slots. Previously, we had to
      do some CPP hacks in order to emit an #ifdef into the file - this is
      because we preprocess it once up front, and run the preprocessor again
      when we compile it.
      
      There's two cases: the boostrap compiler is > 7.8, and the stage1 parser
      needs the flag, or the stage1 compiler is compiling the stage2
      Parser.hs, and needs the flag..
      
      The previous approach was super fragile with Clang. The more principled
      fix is to instead do this through the build system.
      
      This fixes #8182.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      9e133b9d
  24. 03 Jul, 2013 1 commit
    • ian@well-typed.com's avatar
      Change the ranlib detection · c548fec4
      ian@well-typed.com authored
      On Windows, the ranlib in the path may not be the right ranlib (it may
      be the 32bit ranlib when we are making a Win64 compiler, or vice-versa).
      Therefore we can't leave it up to libffi to detect the right ranlib, but
      need to tell it which ranlib to use. This means that we need to find
      ranlib even if we don't actually need it ourselves.
      c548fec4
  25. 17 Jun, 2013 1 commit
    • thoughtpolice's avatar
      Detect linker information at runtime. Fixes Trac #6063 · 71a194d8
      thoughtpolice authored
      
      
      Previously, we did ./configure time checks to see if 'GNU ld' supported
      certain options. If it does, we bake those options into the link step.
      See Trac #5240.
      
      Unfortunately, the linker we use at runtime can change for several
      reasons. One is that the user specifies -pgml 'foo'. The other is if
      /usr/bin/ld or whatnot changes from when GHC was built.  Those options
      mentioned earlier are specific to GNU ld, but many systems support GNU
      gold too. This is Trac #6063.
      
      So we need to check at runtime what linker we're using. This is actually
      a little bit complicated because we normally use the C compiler as our
      linker. Windows and OS X are also special here.
      
      Finally, this patch also unconditionally gives '--hash-size=31' and
      '--reduce-memory-overheads' to the system linker if it's GNU ld. These
      options have been supported for 8+ years from what I can see, and there
      are probably a lot of other reasons why GHC would not work with such an
      ancient binutils, all things considered.
      
      See Note [Run-time linker info] in SysTools for details. There are
      plenty of comments as well in the surrounding code.
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      71a194d8
  26. 09 Jun, 2013 2 commits
  27. 20 Apr, 2013 1 commit
  28. 23 Mar, 2013 1 commit
  29. 18 Mar, 2013 1 commit
  30. 05 Mar, 2013 1 commit
  31. 02 Mar, 2013 1 commit
  32. 01 Mar, 2013 1 commit
  33. 17 Feb, 2013 3 commits
  34. 14 Feb, 2013 1 commit