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

 Replying to [comment:4 Phyx-]:
 > Hi Matt,
 >
 > Thanks for the patch!, I will look at it more closely in the weekend.
 But a few things:
 >
 > 1) This does not look for `.lib` files which are just import libs as
 well

 If you check existing archive loading mechanics in GHCi it doesn't look
 for `.lib` files either. Those files are usually produces by MSVC compiler
 which its not officially supported by GHC as far as i know.

 I think preferable way of getting libraries on Windows should be MSYS2
 anyway as it uses the same compiler as GHC and already comes with really
 big collection of packages.

 > 2) I'm a bit weary of having to look for a specific section group.
 >    In particular the `.lib` from from `icuuc.lib` does not have an
 `.idata$7`.

 Sadly the exact naming conventions, structure and binary format of this
 files seems to be very much compiler dependent.
 I've made no attempt so far to try to target anything except MinGW GCC.

 > I think it should just be running through the `.idata` sections to find
 it.

 I did that in my initial implementation, but then i decided to narrow it
 down to that specific section in first object file after i saw that its
 there consistently in all import libraries that ship with MinGW and in all
 libraries i have installed in my local MSYS2 folder.

 > 3) We already have code to read in COFF files in `Linker.c`, we probably
 don't want to maintain this at two points. So I would have expected most
 of the logic here to be done on the C side.

 That code is specific to loading of static archives, but i guess it could
 be duplicated and adapted for this. Still i prefer to work in Haskell land
 as much as i can. :)

 > I have also been wondering, these import libs also contain large symbol
 tables. Presumably because import libraries contain stubs for calling into
 the dll.
 >
 > GHCi supports dynamic loading of archives, would it not be possible to
 just simply satisfy the linker by just satisfying the symbol resolution
 with these stubs? Sure we have an extra layer of indirection, but it would
 be robust and it wouldn't really matter much for the repl.

 That would certainly be the best solution, but it would requires some more
 modifications to the linker (see comment bellow). However since I'm not
 very familiar with specifics of dynamic object code loading I can't help
 much with that.

 > What I am asking is, have you considered just correctly locating these
 import libs and then not returning a `DLL` but an `Archive`? In theory
 this should still work, but you wouldn't have to read the COFF files.

 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`:
 {{{
 C:\Dev\ghc-7.10.2\bin>ghci -Lc:\msys32\mingw32\lib -lz.dll
 GHCi, version 7.10.2: http://www.haskell.org/ghc/  :? for help
 ghc.exe: internal error: checkProddableBlock: invalid fixup in runtime
 linker: 090a00dc
     (GHC version 7.10.2 for i386_unknown_mingw32)
     Please report this as a GHC bug:
 http://www.haskell.org/ghc/reportabug

 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.
 }}}

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