[GHC] #11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows
#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) | Keywords: | Operating System: Windows Architecture: | Type of failure: Runtime crash Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- (This is adapted from the comments [https://github.com/bos/text- icu/issues/12#issuecomment-154452774 here].) On Windows, the GHC runtime linker only searches for DLLs that have the same names as the import libraries passed to `-l`. This can sometimes create problems, since a library name could be different from the DLL it needs. `text-icu` provides an example of this, since it needs the extra libraries `icuuc`, `icudt`, and `icuin`. However, if you download the [http://site .icu-project.org/download/56#TOC-ICU4C-Download official ICU 56 binaries], they are distributed with DLLs named `icuuc56.dll`, `icudt56.dll`, and `icuin56.dll`, rather than `icuuc.dll`, `icudt.dll`, and `icuin.dll`. This doesn't create any trouble for the linker at compile-time. In fact, if you compile this program {{{#!hs -- TextICU.hs import Data.Text.ICU.Break main = print Kana }}} with `ghc TextICU.hs` and then run `cygcheck ./TextICU.hs` without having the ICU4C `bin64` folder in your `PATH`, it ''appears'' to search for the right DLLs: {{{ $ cygcheck ./TextICU.hs ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll }}} But actually running the code reveals a different story: {{{ $ runghc TextICU.hs TextICU.hs: icuuc: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc.dll (addDLL: could not load DLL) }}} This demonstrates that the runtime linker behaves differently; it is dependent on what the linked libraries' names are. To confirm this, you can recompile `text-icu` with the following changes to `text-icu.cabal`: {{{ extra-libraries: icuuc56 if os(mingw32) extra-libraries: icuin56 icudt56 }}} Also make symlinks named `icuuc56.lib`, `icuin56.lib`, and `icudt56.lib` that refer to `icuuc.lib`, `icuin.lib`, and `licudt.lib`, respectively, in the ICU4C `lib64` directory. Now `cygcheck` and `ghc` agree on which DLLs to use: {{{ $ ghc TextICU.hs $ cygcheck ./TextICU.exe ... cygcheck: track_down: could not find icuin56.dll cygcheck: track_down: could not find icuuc56.dll $ runghc TextICU.hs TextICU.hs: icuuc56: The specified module could not be found. TextICU.hs: <command line>: can't load .so/.DLL for: icuuc56.dll (addDLL: could not load DLL) }}} -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): I have been playing with this for few months now and i have my own patched GHC that can in rather hackish way resolve real DLL name from import library. It does so by guessing it from 2 symbol names that only seem to appear in import libraries. However its not 100% accurate. I have been looking for better way to find that info and and so far i found that in all import libraries DLL name seems to be in {{{.idata$7}}} section in some random object file. Also most object files have {{{.idata$7}}} section, but all but that one have either no data associated with it or some have just NULLs stored in there. I'm now working on little test program that will parse import library and try to extract DLL name from {{{.idata$7}}} section. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:1 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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, I am happy for you to take this over if you want. I haven't had the time to start on it yet or to take a look at what's involved in implementing it. So it is still up for grabs :) -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:2 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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): @Phyx- I have never before submitted a patch for GHC so i have no idea if i would be able to take over this ticket and what would be proper procedure for going with it. However i have been working on this for few days here is what i got so far. After examining many import libraries i found out that in all import libraries i got my hands on, DLL name was always stored in first object file in import library archive in raw data associated with {{{idata$7}}} section. Based on that i think this is reliable way to implement this. I put together small patch for GHC, however its for GHC-7.10.2 as i have some trouble building and running GHC-head on my PC. In spite of that it should be trivial to port this to head as it changes only few lines of existing code. I would love to hear some input on this and whether this seems viable. In the meantime if I manage to build and test this with GHC-head I will post more update. At the moment with this patch when you invoke GHCi, for example as {{{ghci -lfoo}}}, it will look for {{{libfoo.dll.a}}} and {{{libfoo.a}}} before trying to load libfoo.a as static library. If either of those 2 are found it will try to extract DLL name from them in that order. If this succeds and assuming DLL name fetched was {{{libfoo-1.dll}}}, it will then try to load {{{libfoo-1.dll}}} instead trying to load {{{libfoo.a}}} as static archive. GHCi will also print some trace info when invoked with {{{-v}}} so that in case of trouble it can be traced back from where did DLL name came from. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Changes (by Matt): * Attachment "implib-ghc.7.10.2.patch" added. Proposed implementation -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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
#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
#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 YitzGale): Replying to [comment:5 Matt]:
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'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.
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.
MSYS2 is very nice, but its "really big collection of packages" is insignificant compared to the amount of libraries compiled with MSVC and available as lib + DLL. And that's just open source - for proprietary libraries that commercial users of GHC need to link against, MSVC is basically the only option. Mingw is designed to support those, and it has always worked fine in the past. MSYS2 is a rock-solid option, when it's available. And we were grateful for that for {{{text-icu}}}. But is seems to me that it will always be a fallback. The normal way to link to a third-party library on Windows is with .lib files and DLLs. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:6 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
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 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. When you for example try to link against foo by `ghc -libfoo ...` that option is passed to GCC as GCC is used for linking everything together into final executable or DLL, and GCC can usually link against `.lib` files, unless you try to link against C++ mangled function names of course. But when you invoke `ghci -lfoo ....` now GHCi-s internal linker is used for linking, and he resolves external libraries a bit differently, as you can see in `locateLib` funtion. First it tries to load `foo.dll` and `libfoo.dll`. If that fails it resorts to loading of static archive followed by some more logic after that. However, important distinction between GHCi linker and GCCs linker on Windows is that GHCi can't resolve DLL name from import library. as explained in description of this ticked.This only becomes apparent when DLL name is different than import library name (which is the case with almost all libraries that come with MSYS2). -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:7 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
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
#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): Here is new patch against HEAD. I expanded search on all `.idata` sections in first object file that comes after archive members and this now seems to work also with import libraries produced by MSVC alongside with those produced by GCC. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:9 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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: | -------------------------------------+------------------------------------- Changes (by Matt): * Attachment "0001-Resolving-DLL-name-from-import-library-in-GHCi.patch" added. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#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-):
Thanks for the patch. We do code reviews on Phabricator (called a
Differential), could you create an account there
https://phabricator.haskell.org/ and upload the patch?
when you do edit this ticket and set the "Differential Rev." field to
"Phab:D
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch 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): D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Matt): * status: new => patch * differential: => D1564 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:11 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: bug | Status: patch 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): Phab:D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by RyanGlScott): * differential: D1564 => Phab:D1564 -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:12 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Matt Type: bug | Status: patch 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): Phab:D1564 Wiki Page: | -------------------------------------+------------------------------------- Changes (by Phyx-): * cc: Phyx- (added) * owner: Phyx- => Matt -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:13 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: patch 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: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: Matt => Phyx- * testcase: => T11072gcc T11072msvc * differential: Phab:D1564 => Phab:D1564 Phab:D1696 * type: bug => feature request -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:14 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Type: feature request | 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: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by bgamari): * owner: Phyx- => * status: patch => new Comment: Punting out of patch status while the remaining issues are sorted out. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | 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: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by Phyx-): * owner: => Phyx- -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:16 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: patch 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: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: new => patch -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:17 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: patch 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: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Comment (by Phyx-): Turns out the GCC import libraries contain mostly ASCII text and very little program code. What it does contain is invalid. So I reverted to an approach similar to what @Matt had except at the `Linker.c` level. Also while theoretically possible I haven't seen an import library pointing to more than one DLL at a time. So I removed the code to handle that to simplify things. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:18 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: patch Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by bgamari): * milestone: 8.0.1 => 8.0.2 Comment: Punting to 8.0.2. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:19 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on
Windows
-------------------------------------+-------------------------------------
Reporter: RyanGlScott | Owner: Phyx-
Type: feature request | Status: patch
Priority: normal | Milestone: 8.0.2
Component: Compiler | Version: 7.10.2-rc2
(Linking) |
Resolution: | Keywords:
Operating System: Windows | Architecture:
| Unknown/Multiple
Type of failure: Runtime crash | Test Case: T11072gcc
| T11072msvc
Blocked By: | Blocking:
Related Tickets: | Differential Rev(s): Phab:D1564
Wiki Page: | Phab:D1696
-------------------------------------+-------------------------------------
Comment (by Tamar Christina
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by Phyx-): * status: patch => closed * resolution: => fixed -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:21 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: merge Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by thomie): * status: closed => merge -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
#11072: Runtime linker doesn't search for DLLs referenced in import libraries on Windows -------------------------------------+------------------------------------- Reporter: RyanGlScott | Owner: Phyx- Type: feature request | Status: closed Priority: normal | Milestone: 8.0.2 Component: Compiler | Version: 7.10.2-rc2 (Linking) | Resolution: fixed | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: T11072gcc | T11072msvc Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1564 Wiki Page: | Phab:D1696 -------------------------------------+------------------------------------- Changes (by bgamari): * status: merge => closed Comment: Merged to `ghc-8.0` as 4f6960bff673525ba399f769e1e585c0475c8ca9. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/11072#comment:23 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC