#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.
I have also been wondering, these import libs also contain large symbol
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. :) tables. Presumably because import libraries contain stubs for calling into the dll.
GHCi supports dynamic loading of archives, would it not be possible to
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
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. 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