1. 17 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Fix archive loading on Windows by the runtime loader · acce37f3
      Tamar Christina authored
      The runtime loader is unable to find archive files `.a` shipping
      with the inplace `GCC`.
      
      It seems the issue is caused by `findArchive` being unable to
      find any archives that are shipped using the in-place `GCC`.
      
      - It works on Linux because `findArchive` would search
        the standard Linux include path.
      - It works during compilation because `GCC` can find it's own libraries
        (we explicitly tell it where to look for libraries using the `gcc`
        wrapper around `realgcc`)
      
      So fixing the issue means using `searchForLibUsingGcc` in `findArchive`
      as well, which will then find the correct file.
      
      The reason for the error as it is, is because if we can't locate the
      library using any of the methods we have, we assume it is a system dll,
      or something on the system search path.  e.g. if trying to load
      `kernel32.dll`.
      
      There is a slight issue in that the `GHCi` code (incorrectly) favors
      `static archives` over `dynamic` ones
      
      ```
      findDll        `orElse`
      findArchive    `orElse`
      tryGcc         `orElse`
      tryGccPrefixed `orElse`
      assumeDll
      ```
      This has the unwanted effect of when `kernel32` is specified as a lib,
      it will try to load `kernel32.a` instead of `kernel32.dll`.
      
      To solve this I have added another search function that is able to
      search the Windows search paths using `SearchPath` in order to find if
      it is a dll on the system search path.
      
      The new search order is:
      
      ```
      findDll     `orElse`
      findSysDll  `orElse`
      tryGcc      `orElse`
      findArchive `orElse`
      assumeDll
      ```
      
      (`tryGccPrefixed` was rolled into `tryGcc` so it is no longer needed at
      top level)
      
      Test Plan: ./validate added new windows tests T3242
      
      Reviewers: thomie, erikd, hvr, austin, bgamari
      
      Reviewed By: thomie, erikd, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1455
      
      GHC Trac Issues: #3242
      acce37f3
  2. 08 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Fix sporadic failing ghci/Linker/Dyn tests · f4056324
      Tamar Christina authored
      Summary:
      Multiple tests use the same source C file.
      GHC was previously writing the resulting .o files
      in the same folder as the source. When these tests
      are run in parallel, sometimes one of the calls would
      use the partial .o file and throw an error.
      
      The .o files are moved into different folders with this
      change.
      
      Test Plan: make test -C testsuite/tests/ghci/linking/dyn
      
      Reviewers: thomie, austin, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1449
      f4056324
  3. 07 Nov, 2015 1 commit
    • Tamar Christina's avatar
      Allow the GHCi Linker to resolve related dependencies when loading DLLs · 6e6438e1
      Tamar Christina authored
      Summary:
      GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's
      that are not on the standard Windows load path:
      
      1. The directory from which the application loaded.
      2. The current directory.
      3. The system directory. Use the GetSystemDirectory function to get the path of this directory.
      4. The 16-bit system directory. There is no function that obtains the path of this directory,
         but it is searched.
      5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory.
      6. The directories that are listed in the PATH environment variable.
         Note that this does not include the per-application path specified by the
         AppPaths registry key. The App Paths key is not used when computing the DLL search path.
      
      So what this means is given two DLLs `A` and `B` and `B` depending on `A`.
      If we put both DLLs into a new folder bin and then call GHC with:
      
      `ghc -L$(PWD)/bin -lB`
      
      the loading will fail as the Windows loader will try to load the dependency of `B` and fail
      since it cannot find `A`.
      
      *IMPORTANT* this patch drops XP Support.
      The  APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista
      via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has
      not been installed on certain machines. For those machines I display a warning and
      temporarily expand the `PATH` to allow it to load.
      
      This patch will make sure that paths provided by the user with `-L` *and* the folder in which a
      DLL is found are added to the search path. It does so using one of two methods depending upon how
      new of a Windows version we are running on:
      
      - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`.
         The order of which these directories are searched is nondeterministic.
      - If the APIs are not available it means that we're running on a pretty old unpatched machine.
        But if it's being used in an environment with no internet access it may be the case.
        So if the APIs are not available we temporarily extend the `PATH` with the directories.
        A warning is also displayed to the user informing them that the linking may fail,
        and if it does, install the needed patch. The `PATH` variable has limitations.
      
      Test Plan:
      ./validate
      
      Added two new test T10955 and T10955dyn
      
      Reviewers: erikd, bgamari, thomie, hvr, austin
      
      Reviewed By: erikd, thomie
      
      Subscribers: #ghc_windows_task_force
      
      Differential Revision: https://phabricator.haskell.org/D1340
      
      GHC Trac Issues: #10955
      6e6438e1
  4. 15 Oct, 2015 1 commit
    • Simon Marlow's avatar
      ELF/x86_64: map object file sections separately into the low 2GB · 04e83666
      Simon Marlow authored
      On 64-bit ELF we need to link object files into the low 2GB due to the
      small memory model.  Previously we would map the entire object file
      using MAP_32BIT, but the object file can consist of 75% or more
      symbols, which only need to be present during linking, so this is
      wasteful.  In our particular application, we're already running out of
      space here.
      
      This patch changes the way we load object files on ELF platforms so
      that the object is first mapped above the 2GB boundary, parsed, and
      then the important sections are re-mapped into the low 2GB area.
      
      Test Plan:
      validate
      (also needs testing on OS X & Windows, preferably 32 & 64 bit)
      
      Reviewers: Phyx, trommler, bgamari, austin
      
      Subscribers: hsyl20, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D975
      04e83666
  5. 10 Oct, 2015 2 commits
  6. 12 Aug, 2015 1 commit
    • Tamar Christina's avatar
      Upgrade GCC to 5.2.0 for Windows x86 and x86_64 · 7b211b4e
      Tamar Christina authored
      This patch does a few things
      
      - Moved GHC x86 to MinGW-w64 (Using Awson's patch)
      - Moves Both GHCs to MSYS2 toolchains
      - Completely removes the dependencies on the git tarball repo
        - Downloads only the required tarball for the architecture for
          which we are building
        - Downloads the perl tarball is missing as well
        - Fixed a few bugs in the linker to fix tests on Windows
      
      The links currently point to repo.msys2.org and GitHub, it might be
      more desirable to mirror them on
      http://downloads.haskell.org/~ghc/mingw/ as with the previous patch
      attempt.
      
      For more details on what the MSYS2 packages I include see #10726
      (Awson's comment). but it should contain all we need
      and no python or fortran, which makes the uncompressed tar a 1-2
      hundreds mb smaller.
      
      The `GCC 5.2.0` in the package supports `libgcc` as a shared library,
      this is a problem since
      when compiling with -shared the produced dll now has a dependency on
      `libgcc_s_sjlj-1.dll`.
      To solve this the flag `-static-libgcc` is now being used for all GCC
      calls on windows.
      
      Test Plan:
      ./validate was ran both on x86 and x86_64 windows and compared against
      the baseline.
      
      A few test were failing due to Ld no longer being noisy. These were
      updated.
      
      The changes to the configure script *should* be validated by the build
      bots for the other platforms before landing
      
      Reviewers: simonmar, awson, bgamari, austin, thomie
      
      Reviewed By: thomie
      
      Subscribers: #ghc_windows_task_force, thomie, awson
      
      Differential Revision: https://phabricator.haskell.org/D1123
      
      GHC Trac Issues: #10726, #9014, #9218, #10435
      7b211b4e
  7. 11 Jun, 2015 1 commit
  8. 04 Jun, 2015 1 commit
    • thomie's avatar
      Testsuite: add/fix cleanup for certain tests · e340f6ec
      thomie authored
      * extra_clean argument should be a list
        Add an assert to prevent regressions.
      
      * properly clean package conf direcories
        They are directories now, which was causing problems.
      
      * properly clean write_interface_* tests
        We were getting these errors:
      
        [Errno 21] Is a directory: './driver/write_interface_oneshot'
        [Errno 39] Directory not empty: './driver/write_interface_oneshot'
        [Errno 21] Is a directory: './driver/write_interface_make'
        [Errno 39] Directory not empty: './driver/write_interface_make'
      
      * outputdir() is better than -outputdir, as it knows how to (pre)clean
        itself.
      e340f6ec
  9. 16 Sep, 2014 1 commit
  10. 29 Aug, 2014 1 commit
  11. 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
      explosion.
      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
      66218d15
  12. 14 Jan, 2014 1 commit
  13. 25 Oct, 2013 1 commit
  14. 22 Aug, 2013 1 commit
  15. 11 Feb, 2013 3 commits
  16. 04 Feb, 2013 1 commit
  17. 12 Oct, 2012 2 commits
  18. 03 Oct, 2012 1 commit
  19. 15 May, 2012 1 commit
  20. 05 May, 2012 1 commit
  21. 03 May, 2012 2 commits
  22. 13 Dec, 2011 1 commit
  23. 01 Dec, 2011 1 commit
  24. 09 Nov, 2011 1 commit
  25. 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.
      995b512c
  26. 03 Aug, 2011 2 commits