1. 19 May, 2009 1 commit
  2. 17 May, 2009 1 commit
  3. 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.
  4. 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.
  5. 20 May, 2009 5 commits
  6. 19 May, 2009 2 commits
  7. 18 May, 2009 1 commit
  8. 15 May, 2009 2 commits
  9. 14 May, 2009 2 commits
  10. 13 May, 2009 4 commits
  11. 01 May, 2009 1 commit
    • Duncan Coutts's avatar
      Make ghc -dynamic imply -fPIC for C code · 431e40e1
      Duncan Coutts authored
      As is already the case for ghc -fPIC. This is needed because ghc -dynamic
      means to generate code that is capable of being linked to Haskell shared
      libs and for C code the equivalent is -fPIC. Normally C code does not need
      -fPIC merely to link to shared libs however Haskell shared libs do not
      follow common conventions. In particular the static data cannot be
      referenced statically because it cannot be copied by the static linker.
      The linker cannot copy them because we do not specify a .size for the
      _closure entries (in the .data section) though in principle we could.
  12. 13 May, 2009 1 commit
  13. 22 Apr, 2009 1 commit
  14. 12 May, 2009 1 commit
    • simonpj@microsoft.com's avatar
      Improve error messages for type functions · da2e18b9
      simonpj@microsoft.com authored
      Following a suggestion of Claus Reinke, this patch improves the error
      messages involving type functions.  Here's the relevant note from TcTyFuns.
      Note [Non-injective type functions]
      It's very confusing to get a message like
           Couldn't match expected type `Depend s'
                  against inferred type `Depend s1'
      so pp_open_tc adds:
             NB: `Depend' is a (non-injective) type function
      Currently we add this independently for each argument, so we also get
           Couldn't match expected type `a'
                  against inferred type `Dual (Dual a)'
             NB: `Dual' is a (non-injective) type function
      which is arguably redundant.  But on the other hand, it's probably
      a good idea for the programmer to know the error involves type functions
      so I've left it in for now.  The obvious alternative is to only add
      this NB in the case of matching (T ...) ~ (T ...). 
  15. 29 Apr, 2009 1 commit
  16. 28 Apr, 2009 2 commits
  17. 27 Apr, 2009 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Equality constraint solver is now externally pure · 296058a1
      chak@cse.unsw.edu.au. authored
      - This patch changes the equality constraint solver such that it does not
        instantiate any type variables that occur in the constraints that are to be
        solved (or in the environment).  Instead, it returns a bag of type bindings.
      - If these type bindings (together with the other results of the solver) are
        discarded, solver invocation has no effect (outside the solver) and can be
        repeated (that's imported for TcSimplifyRestricted).
      - For the type bindings to take effect, the caller of the solver needs to 
        execute them. 
      - The solver will still instantiate type variables thet were created during 
        solving (e.g., skolem flexibles used during type flattening).
        See also http://hackage.haskell.org/trac/ghc/wiki/TypeFunctionsSolving
  18. 26 Apr, 2009 2 commits
  19. 25 Apr, 2009 1 commit
  20. 24 Apr, 2009 7 commits
  21. 23 Apr, 2009 1 commit