1. 26 Feb, 2017 5 commits
    • Tamar Christina's avatar
      Load `pthreads` by default on Windows · be3f4362
      Tamar Christina authored
      The GCC Bindists that we use compile with `pthread` enabled by default.
      This means that on every link the dll is passed as a dependency by the
      driver. Lots of packages depend on it but the runtime linker doesn't
      provide it by default making compiled code work but not interpreted.
      Following D3028 `pthreads` would be provided by default ONLY when linked
      dynamicly, which we don't support yet (See D2592). Until this is the
      case we need to manually provide `libpthreads`.
      Test Plan: ./validate
      Reviewers: austin, hvr, bgamari
      Reviewed By: bgamari
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D3155
    • Tamar Christina's avatar
      Make list of deprecated symbols on Windows weak. · 9968502d
      Tamar Christina authored
      We have a unfortunate workaround in place for the fact that most
      packages out there use POSIX names for symbols even on Windows.  This
      means that we have to recognize e.g. both `_ungetch` and `ungetch`.
      The former is the actual symbol name on windows and the latter is the
      POSIX variant. The problem is that on normal windows programs `ungetch`
      should not be in the global namespace.
      To work around this, we now mark the deprecated symbols as weak symbols
      in the global namespace. This provides the flexibility we need:
      * If you use the symbol without defining it, we assume you meant to use
        the POSIX variant.
      * If you actually define the symbol, we'll hence forth use that
        definition and assume you didn't mean to use POSIX code. This is how
        MingW64's wrapper also works.
      This requires D3028.
      Fixes #13210.
      Test Plan: ./validate
      Reviewers: austin, bgamari, erikd, simonmar
      Reviewed By: bgamari
      Subscribers: thomie, #ghc_windows_task_force
      Differential Revision: https://phabricator.haskell.org/D3154
    • 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
    • Alan Zimmerman's avatar
    • Edward Z. Yang's avatar
      Rename compact to ghc-compact. · a0b4a2ac
      Edward Z. Yang authored
      The plan is to release a separate library, 'compact', which gives a
      friendly user-facing interface.  This library is just enough so that we
      can make sure the functionality is working in GHC.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      Test Plan: validate
      Reviewers: bgamari, dfeuer, austin, simonmar, hvr
      Subscribers: thomie, erikd, snowleopard
      Differential Revision: https://phabricator.haskell.org/D3206
  2. 25 Feb, 2017 3 commits
  3. 24 Feb, 2017 6 commits
  4. 23 Feb, 2017 19 commits
  5. 22 Feb, 2017 7 commits