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