[GHC] #3242: GHCi linker does not correctly locate static libraries under Windows

[GHC]

#3242: GHCi linker does not correctly locate static libraries under Windows
---------------------------------+----------------------------------------
        Reporter:  jeffz1        |                Owner:  Phyx-
            Type:  bug           |               Status:  patch
        Priority:  high          |            Milestone:  7.10.3
       Component:  GHCi          |              Version:  7.4.1
      Resolution:                |             Keywords:
Operating System:  Windows       |         Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown  |            Test Case:  T3242
      Blocked By:  3658          |             Blocking:
 Related Tickets:  #7097         |  Differential Rev(s):  Phab:D1455
       Wiki Page:                |
---------------------------------+----------------------------------------

Comment (by Ben Gamari <ben@…>):

 In [changeset:"acce37f38bc3867f86cf717694915746bb2f278e/ghc" acce37f/ghc]:
 {{{
 #!CommitTicketReference repository="ghc"
 revision="acce37f38bc3867f86cf717694915746bb2f278e"
 Fix archive loading on Windows by the runtime loader

 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
 }}}

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/3242#comment:46>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler