1. 13 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #9438 by converting a panic to an error message · 7613a812
      Ryan Scott authored
      Previously, GHC was quite eager to panic whenever it was fed
      an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
      explicit error message instead, so this patch accomplishes just that.
      Test Plan: make test TEST=T14708
      Reviewers: Phyx, hvr, bgamari
      Reviewed By: Phyx
      Subscribers: thomie, carter
      GHC Trac Issues: #9438, #14708, #15032
      Differential Revision: https://phabricator.haskell.org/D4589
  2. 26 Feb, 2017 1 commit
    • Tamar Christina's avatar
      Load dependent dlls. · 41e54b4b
      Tamar Christina authored
      When the `GCC` driver envokes the pipeline a `SPEC` is used to determine
      how to configure the compiler and which libraries to pass along.
      For Windows/mingw, this specfile is
      This has a lot of interesting things that we need to emulate in order to
      be able to link as many things out of the box as GCC. In particular this
      is why you never need to specify `-lgcc_s` when compiling, but you do
      when using `GHCi`.
      Unfortunately due to time constraints I can't set up the framework
      required in `GHC` to do this before the feature freeze.
      So I suggest this alternate implementation:
      When we load a dll, also bring it's dependencies into scope of the
      This has pros and cons. Pro is, we'll fix many packages on hackage which
      specify just `-lstdc++`. Since this points to `libstdc++-6.dll` which
      will bring `libgcc` into scope.
      The downside is, we'll be more lenient than GCC, in that the interpreter
      will link much easier since it has implicit dependencies in scope.
      Whereas for compilation to work you will have to specify it as an
      argument to GHC.
      This will make the Windows runtime linker more consistent with the unix
      ones. The difference in semantics came about because of the differences
      between `dlsym` and `GetProcAddress`.  The former seems to search the
      given library and all it's dependencies, while the latter only searches
      the export table of the library. So we need some extra manual work to
      search the dependencies which this patch provides.
      Test Plan:
      $ echo :q | inplace/bin/ghc-stage2.exe --interactive +RTS -Dl -RTS
      -lstdc++ 2>&1 | grep "Loading dependency"
      $ echo :q | ../inplace/bin/ghc-stage2.exe --interactive -lstdc++ +RTS
      -Dl -RTS 2>&1 | grep "Loading dependency"
      Loading dependency *.exe -> GDI32.dll.
      Loading dependency GDI32.dll -> ntdll.dll.
      Loading dependency *.exe -> KERNEL32.dll.
      Loading dependency KERNEL32.dll -> KERNELBASE.dll.
      Loading dependency *.exe -> msvcrt.dll.
      Loading dependency *.exe -> SHELL32.dll.
      Loading dependency SHELL32.dll -> USER32.dll.
      Loading dependency USER32.dll -> win32u.dll.
      Loading dependency *.exe -> WINMM.dll.
      Loading dependency WINMM.dll -> WINMMBASE.dll.
      Loading dependency *.exe -> WSOCK32.dll.
      Loading dependency WSOCK32.dll -> WS2_32.dll.
      Loading dependency WS2_32.dll -> RPCRT4.dll.
      Loading dependency libstdc++-6.dll -> libwinpthread-1.dll.
      Loading dependency libstdc++-6.dll -> libgcc_s_seh-1.dll.
      Trac tickets: #13093, #13189
      Reviewers: simonmar, rwbarton, austin, bgamari, erikd
      Reviewed By: bgamari
      Subscribers: rwbarton, RyanGlScott, thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D3028
  3. 24 Jan, 2017 1 commit
  4. 27 May, 2016 1 commit
  5. 10 Feb, 2016 1 commit
    • Edward Z. Yang's avatar
      Error early when you register with too old a version of Cabal. · d80caca1
      Edward Z. Yang authored
      On the GHC 8.0 RCs, multiple users reported a very strange error
      whereby GHC would complain that the symbols names recorded in interface
      files did not match the expected name.  The reason for this is
      that they were using an old version of Cabal which chose symbol
      names differently from the installed package ID ('id' field) which
      the package was to be installed with; GHC 8.0 now mandates that
      these coincides.
      This change adds a test to ghc-pkg to make sure that 'id' and 'key'
      (which is how Cabal previously reported what the symbol name
      was supposed to be) match; if they don't match or key is missing,
      we assume that the Cabal was too old.
      Bikeshed points:
          - Should we offer more information about how to upgrade
            Cabal correctly (i.e. specify a version?)
          - Should we allow for a missing 'key'?  If we allow for
            'key' to be missing, we lose the ability to detect
            Cabal from GHC 7.8 or earlier being used.  If we
            require it to be specified, then it will not be possible
            for Cabal to deprecate the (unused) field and remove it
            without having BC for 8.0.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: austin, bgamari, hvr
      Reviewed By: hvr
      Subscribers: bergmark, thomie
      Differential Revision: https://phabricator.haskell.org/D1892
      GHC Trac Issues: #11558
  6. 10 Oct, 2015 1 commit
    • Tamar Christina's avatar
      Add short library names support to Windows linker · 5d841108
      Tamar Christina authored
      Make Linker.hs try asking gcc for lib%s.dll as well, also changed tryGcc
      to pass -L to all components by using -B instead. These two fix
      shortnames linking on windows.
      re-enabled tests: ghcilink003, ghcilink006 and T3333
      Added two tests: load_short_name and enabled T1407 on windows.
      Reviewed By: thomie, bgamari
      Differential Revision: https://phabricator.haskell.org/D1310
      GHC Trac Issues: #9878, #1407, #1883, #5289
  7. 29 Aug, 2014 1 commit
  8. 05 Aug, 2014 1 commit
    • Edward Z. Yang's avatar
      Package keys (for linking/type equality) separated from package IDs. · 66218d15
      Edward Z. Yang authored
      This patch set makes us no longer assume that a package key is a human
      readable string, leaving Cabal free to "do whatever it wants" to allocate
      keys; we'll look up the PackageId in the database to display to the user.
      This also means we have a new level of qualifier decisions to make at the
      package level, and rewriting some Safe Haskell error reporting code to DTRT.
      Additionally, we adjust the build system to use a new ghc-cabal output
      Make variable PACKAGE_KEY to determine library names and other things,
      rather than concatenating PACKAGE/VERSION as before.
      Adds a new `-this-package-key` flag to subsume the old, erroneously named
      `-package-name` flag, and `-package-key` to select packages by package key.
      RFC: The md5 hashes are pretty tough on the eye, as far as the file
      system is concerned :(
      ToDo: safePkg01 test had its output updated, but the fix is not really right:
      the rest of the dependencies are truncated due to the fact the we're only
      grepping a single line, but ghc-pkg is wrapping its output.
      ToDo: In a later commit, update all submodules to stop using -package-name
      and use -this-package-key.  For now, we don't do it to avoid submodule
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: simonpj, simonmar, hvr, austin
      Subscribers: simonmar, relrod, carter
      Differential Revision: https://phabricator.haskell.org/D80
  9. 25 Oct, 2013 1 commit
  10. 03 Oct, 2012 1 commit
  11. 15 May, 2012 1 commit
  12. 05 May, 2012 1 commit
  13. 03 May, 2012 1 commit
  14. 13 Dec, 2011 1 commit
  15. 05 Aug, 2011 1 commit
    • chak@cse.unsw.edu.au.'s avatar
      Fix remaining test failures on OS X/x86_64 · 995b512c
      chak@cse.unsw.edu.au. authored
      * Adapted the limits of two performance tests for OS X/x86_64
      * ghci/linking tests need to use .dylib for shared libraries on OS X
      Zero test failures on OS X/x86_64 (for the first time, I think)! Let's keep it that way.
  16. 03 Aug, 2011 2 commits