1. 04 Sep, 2013 1 commit
  2. 28 Aug, 2013 1 commit
    • thoughtpolice's avatar
      Rework how iOS does linking (#8127) · 98b0d05d
      thoughtpolice authored
      iOS has some particular constraints about how applications can be built:
      
       * We must generate a static library (.a) since XCode does the final
         link.
       * We need to carefully give the right set of arguments to libtool in
         the case we're generating an archive.
       * Dynamic linking isn't supported.
       * It can only be done on OS X.
      
      This patch cleans up all of the above. We add a new flag `-staticlib`
      (only supported on Darwin) that allows us to produce archive files using
      libtool, and a -pgmlibtool flag to control which 'libtool' executable to
      use.
      
      This fixes #8127. I believe this is the last piece missing from the iOS
      cross compiler.
      Authored-by: lukexi's avatarLuke Iannini <lukexi@me.com>
      Authored-by: maxs's avatarMaxwell Swadling <maxwellswadling@gmail.com>
      Authored-by: default avatarStephen Blackheath <...@blacksapphire.com>
      Signed-off-by: thoughtpolice's avatarAustin Seipp <aseipp@pobox.com>
      98b0d05d
  3. 24 Aug, 2013 2 commits
  4. 14 Aug, 2013 1 commit
  5. 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
  6. 20 Jun, 2013 1 commit
  7. 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
  8. 11 Jun, 2013 1 commit
  9. 07 Jun, 2013 1 commit
  10. 30 May, 2013 1 commit
  11. 20 May, 2013 1 commit
  12. 19 May, 2013 1 commit
  13. 24 Mar, 2013 1 commit
  14. 18 Mar, 2013 1 commit
  15. 10 Mar, 2013 1 commit
  16. 04 Mar, 2013 1 commit
  17. 28 Feb, 2013 1 commit
  18. 25 Feb, 2013 2 commits
    • Gabor Greif's avatar
      Split SettingsCCompilerFlags into non-link and link portions · 890f4657
      Gabor Greif authored
      This fixes certain older GCCs which do not accept link options when assembling or compiling:
      
        ppc_85xx-gcc: --hash-size=31: linker input file unused because linking not done
        ppc_85xx-gcc: --reduce-memory-overheads: linker input file unused because linking not done
      
      and diagnose this to stderr.
      890f4657
    • gmainlan@microsoft.com's avatar
      Fix autoconf code to find LLVM tools. · cdae6654
      gmainlan@microsoft.com authored
      The loop exit condition was testing ${LLC} instead of $1, which was
      incorrect. While I'm here, quote the path being tested since it may contain
      spaces (e.g. on Windows), and don't search paths that don't exist, which
      eliminates un-useful error messages from find.
      cdae6654
  19. 20 Feb, 2013 1 commit
  20. 17 Feb, 2013 4 commits
  21. 14 Feb, 2013 3 commits
  22. 12 Feb, 2013 1 commit
  23. 10 Feb, 2013 2 commits
  24. 06 Feb, 2013 1 commit
  25. 30 Jan, 2013 1 commit
  26. 29 Jan, 2013 1 commit
  27. 25 Jan, 2013 1 commit
  28. 23 Jan, 2013 1 commit
  29. 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:
      
      Before
      ------
      
      To build a cross-compiler:
        ./configure --target=<..>
      
      To compile a foreign GHC:
        ./configure --host=<..> --target=<..>
      
      Now
      ---
      
      To build a cross-compiler:
        ./configure --target=<..>
        And set "Stage1Only=YES" in mk/build.mk
      
      To compile a foreign GHC:
        ./configure --target=<..>
      109a1e53
  30. 05 Dec, 2012 1 commit
  31. 23 Nov, 2012 1 commit
  32. 13 Nov, 2012 1 commit