1. 26 Jul, 2010 1 commit
  2. 24 Jul, 2010 2 commits
  3. 22 Jul, 2010 1 commit
  4. 20 Jul, 2010 1 commit
    • dterei's avatar
      LLVM: Decrease max opt level used under OSX to avoid bug · 726cab79
      dterei authored
      Currently, many programs compiled with GHC at -O2 and LLVM
      set to -O3 will segfault (only under OSX). Until this issue
      is fixed I have simply 'solved' the segfault by lowering
      the max opt level for LLVM used to -O2 under OSX.
      All these recent changes to OSX should mean its finally as
      stable as Linux and Windows.
  5. 13 Jul, 2010 1 commit
  6. 08 Jul, 2010 1 commit
  7. 25 Jun, 2010 1 commit
  8. 22 Jun, 2010 1 commit
  9. 15 Jun, 2010 1 commit
  10. 12 Jun, 2010 1 commit
  11. 20 May, 2010 1 commit
    • Ian Lynagh's avatar
      Stop passing -Wl,-macosx_version_min to gcc · 78b2f856
      Ian Lynagh authored
      Fixes a build failure on OS X 10.6. When linking
      we got
          ld: symbol dyld_stub_binding_helper not defined (usually in crt1.o/dylib1.o/bundle1.o)
          collect2: ld returned 1 exit status
  12. 27 Apr, 2010 1 commit
    • Simon Marlow's avatar
      --make is now the default (#3515), and -fno-code works with --make (#3783) · 7828bf3e
      Simon Marlow authored
      If the command line contains any Haskell source files, then we behave
      as if --make had been given.
      The meaning of the -c flag has changed (back): -c now selects one-shot
      compilation, but stops before linking.  However, to retain backwards
      compatibility, -c is still allowed with --make, and means the same as
      --make -no-link.  The -no-link flag has been un-deprecated.
      -fno-code is now allowed with --make (#3783); the fact that it was
      disabled before was largely accidental, it seems.  We also had some
      regressions in this area: it seems that -fno-code was causing a .hc
      file to be emitted in certain cases.  I've tidied up the code, there
      was no need for -fno-code to be a "mode" flag, as far as I can tell.
      -fno-code does not emit interface files, nor does it do recompilation
      checking, as suggested in #3783.  This would make Haddock emit
      interface files, for example, and I'm fairly sure we don't want to do
      that.  Compiling with -fno-code is pretty quick anyway, perhaps we can
      get away without recompilation checking.
  13. 31 Mar, 2010 1 commit
  14. 20 Mar, 2010 1 commit
  15. 16 Mar, 2010 1 commit
  16. 13 Mar, 2010 3 commits
  17. 29 Jan, 2010 1 commit
  18. 06 Jan, 2010 1 commit
  19. 21 Dec, 2009 1 commit
  20. 30 Sep, 2009 1 commit
  21. 18 Nov, 2009 2 commits
  22. 17 Nov, 2009 1 commit
  23. 14 Nov, 2009 1 commit
  24. 24 Sep, 2009 1 commit
  25. 17 Sep, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix build on Mac OS 10.6 (Snow Leopard) · c2cd83e7
      chak@cse.unsw.edu.au. authored
      - We have -m32 as machine-dependent option for gcc for a 32 bit build
      - Like on OpenBSD, SL requires -fno-stack-protector to avoid triggering the
        stack smashing checks inserted by gcc by default on this platform.
  26. 18 Jul, 2009 1 commit
  27. 14 Jul, 2009 1 commit
  28. 06 Jul, 2009 1 commit
  29. 01 Jul, 2009 1 commit
  30. 10 Jun, 2009 1 commit
  31. 19 May, 2009 1 commit
  32. 15 May, 2009 2 commits
    • Duncan Coutts's avatar
      Set the soname when creating a shared lib · 6efacfe8
      Duncan Coutts authored
      It's still possible to override it, just use -optl-Wl,-soname, eg:
      ghc -shared -dynamic foo.o -o libfoo.so -optl-Wl,-soname,libbar.so
    • Duncan Coutts's avatar
      Keep C main separate from rts lib and link it in for standalone progs · fa00cc50
      Duncan Coutts authored
      Previously the object code for the C main function lived in the rts
      lib, however this is a problem when the rts is built as a shared lib.
      With Windows DLLs it always causes problems while on ELF systems it's a
      problem when the user decides to use their own C main function rather
      than a Haskell Main.main. So instead we now put main in it's own tiny
      little static lib libHSrtsmain.a which we install next to the rts libs.
      Whenever ghc links a program (without -no-hs-main) then it also links
      in -lHSrtsmain. For consistency we always do it this way now rather
      than trying to do it differently for static vs shared libraries.
  33. 14 May, 2009 1 commit
    • Duncan Coutts's avatar
      Remove old Windows-only implementation of keeping main outside the rts · 3d411991
      Duncan Coutts authored
      We now do it for all ways and for all platforms. This was a Windows-only
      version that only kept a separate Main.dyn_o for the dynamic linking case.
      It had to do that because Windows DLLs are stricter about unresolved symbols
      where as for ELF platforms we only run into the problem when we're not using
      a Haskell main function.
  34. 20 May, 2009 1 commit
  35. 13 May, 2009 1 commit