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

16 Nov 2015

      #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-):

 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

 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`.

 {{{
 Dump of file icuuc.lib

 File Type: LIBRARY

   Summary

           C3 .debug$S
           14 .idata$2
           14 .idata$3
            8 .idata$4
            8 .idata$5
            C .idata$6
 }}}

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

 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.

 ---

 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.

 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.

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