1. 23 Mar, 2014 2 commits
  2. 07 Feb, 2014 1 commit
  3. 29 Jan, 2014 1 commit
  4. 28 Jan, 2014 1 commit
  5. 01 Oct, 2013 1 commit
  6. 29 Sep, 2013 1 commit
  7. 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>
  8. 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.
  9. 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>
  10. 09 Jun, 2013 2 commits
  11. 20 Apr, 2013 1 commit
  12. 23 Mar, 2013 1 commit
  13. 18 Mar, 2013 1 commit
  14. 05 Mar, 2013 1 commit
  15. 02 Mar, 2013 1 commit
  16. 01 Mar, 2013 1 commit
  17. 17 Feb, 2013 3 commits
  18. 14 Feb, 2013 2 commits
  19. 11 Feb, 2013 1 commit
  20. 10 Feb, 2013 1 commit
  21. 07 Feb, 2013 2 commits
    • Gabor Greif's avatar
      Clean up AC_PREREQ. · 5b8dc205
      Gabor Greif authored
    • 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.
  22. 06 Feb, 2013 1 commit
  23. 02 Feb, 2013 1 commit
  24. 30 Jan, 2013 1 commit
  25. 25 Jan, 2013 1 commit
  26. 17 Jan, 2013 1 commit
    • Simon Marlow's avatar
      Tidy up cross-compiling · 109a1e53
      Simon Marlow authored
      We have two cases:
       1. building a cross-compiler
       2. compiling GHC to run on a foreign platform
      These two are done with almost the same setup: (1) is the stage 1
      compiler, and (2) is the stage 2 compiler, when CrossCompiling=YES.
      The only difference between (1) and (2) is that you if you set up the
      build for (1), then it stops before stage 2 and you can 'make install'
      to install stage 1.
      Unfortunately, (2) didn't work, and the build system code needed some
      tidying up.
      Change to the way the build is set up:
      To build a cross-compiler:
        ./configure --target=<..>
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/build.mk
      To compile a foreign GHC:
        ./configure --target=<..>
  27. 04 Dec, 2012 2 commits
  28. 30 Nov, 2012 2 commits
  29. 29 Nov, 2012 1 commit
    • ian@well-typed.com's avatar
      Add configure option to use system provided libffi; fixes #5743 · 3005e909
      ian@well-typed.com authored
      Based on patch from Peter Trommler:
          From 293495d40f62e691520331a41c6d85d82e120169 Mon Sep 17 00:00:00 2001
          From: Peter Trommler <ptrommler@acm.org>
          Date: Sun, 21 Oct 2012 18:47:01 +0200
          Subject: [PATCH] Add configure option to use system provided libffi This
           fixes track # 5743 and #4496.
  30. 13 Nov, 2012 3 commits