[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 Kludgy):

 Great insight! I'm really looking forward to this patch. I presume
 `findSysDll` is the new function?

 Replying to [comment:40 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:41>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler