[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows

[GHC]

#11072: Runtime linker doesn't search for DLLs referenced in import libraries on
Windows
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  Phyx-
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:  8.0.1
       Component:  Compiler          |              Version:  7.10.2-rc2
  (Linking)                          |
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  Runtime crash     |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------

Comment (by Phyx-):

 Replying to [comment:7 Matt]:
 > > I'm not sure what you mean by "not officially supported". Specifying
 .lib files + DLL files has always been the standard way to use FFI for
 third party libraries on Windows.
 >
 > In `compiler/ghci/Linker.hs` in function `locateLib` you can see line
 > {{{arch_file = "lib" ++ lib ++ lib_tag <.> "a"}}}. This is how static
 archive name which will GHCi attempt to load is constructed.
 >

 This is just the way it currently is. The Linker also doesn't look for
 `.dll.a` which you added in your patch. The whole goal is to add support
 for import libraries.

 I agree that in the Windows world, outside of the msys2 sandbox, `.lib`
 are far far more common. Given that the most popular compilers on the
 platform produce it.

 But in any case, I am not aware of the format actually being different.
 Both `.dll.a` and `.lib` are `ar` archives of `COFF` files as far as I
 know.

 > Those files are usually produces by MSVC compiler which its not
 officially supported by GHC as far as i know.

 GHC doesn't support compiling with MSVC but it does support linking
 against objects from it. Certainly against loading libs produced by it. At
 the end of the day, it's GCC and GHC that are compatible with Windows not
 the other way around. As in, they produce PE and COFF files according to
 the PE spec.

 > That code is specific to loading of static archives, but i guess it
 could be duplicated and adapted for this.

 It could be that I am missing something here, but I was under the
 impression that the basic format was the same. That it's just used
 different (if at all).

 > I did try that but it seems to fail for me. For example trying to load
 import library for zlib1.dll named libz.dll.a:

 That error is because your patch is based on `7.10.2`. This was fixed for
 `7.10.3`. A lot of work has been done on the Windows linker lately, so it
 may also be best to try again on `head`. I know you had problems compiling
 head, but it should prove much easier there.

 If you need any help or want to discuss further you can always find me in
 the IRC channel :)

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