[GHC] #3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)

[GHC]

#3242: ghci: can't load .so/.DLL for: m (addDLL: could not load DLL)
---------------------------------+-----------------------------
        Reporter:  jeffz1        |                Owner:  Phyx-
            Type:  bug           |               Status:  new
        Priority:  high          |            Milestone:  8.0.1
       Component:  GHCi          |              Version:  7.4.1
      Resolution:                |             Keywords:
Operating System:  Windows       |         Architecture:  x86
 Type of failure:  None/Unknown  |            Test Case:
      Blocked By:  3658          |             Blocking:
 Related Tickets:  #7097         |  Differential Rev(s):
       Wiki Page:                |
---------------------------------+-----------------------------

Comment (by Phyx-):

 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 specific 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)

 This seems to be working well, it is dependent on another patch of mine so
 have to push that one through before this one. But patch coming soon.

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