1. 19 Aug, 2014 2 commits
  2. 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
  3. 13 Aug, 2014 1 commit
  4. 09 Aug, 2014 1 commit
  5. 05 Aug, 2014 1 commit
  6. 04 Jul, 2014 1 commit
  7. 02 Jul, 2014 1 commit
  8. 27 Mar, 2014 2 commits
  9. 23 Mar, 2014 2 commits
  10. 07 Feb, 2014 1 commit
  11. 29 Jan, 2014 1 commit
  12. 28 Jan, 2014 1 commit
  13. 01 Oct, 2013 1 commit
  14. 29 Sep, 2013 1 commit
  15. 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
  16. 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
  17. 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
  18. 09 Jun, 2013 2 commits
  19. 20 Apr, 2013 1 commit
  20. 23 Mar, 2013 1 commit
  21. 18 Mar, 2013 1 commit
  22. 05 Mar, 2013 1 commit
  23. 02 Mar, 2013 1 commit
  24. 01 Mar, 2013 1 commit
  25. 17 Feb, 2013 3 commits
  26. 14 Feb, 2013 2 commits
  27. 11 Feb, 2013 1 commit
  28. 10 Feb, 2013 1 commit
  29. 07 Feb, 2013 2 commits
    • Gabor Greif's avatar
      Clean up AC_PREREQ. · 5b8dc205
      Gabor Greif authored
      5b8dc205
    • Gabor Greif's avatar
      Require autoconf 2.60, as · 0af03de5
      Gabor Greif authored
      version 2.59 seems to be incompatible with our updated macros.
      If somebody insists on 2.59 (which is almost 10 years old) I'll
      have to hunt down the reason for the recent (Dec 2012?) breakage.
      
      Note that I did not check with 2.60 (I have 2.65), so that one
      may still be problematic.
      0af03de5
  30. 06 Feb, 2013 1 commit
  31. 02 Feb, 2013 1 commit
  32. 30 Jan, 2013 1 commit