#10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: new Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (Linker) | 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 thoughtpolice): I proposed quite a while back to actually drop XP support: https://mail.haskell.org/pipermail/ghc-devs/2014-November/007199.html Personally, I say we go for it. Of course, some people might not like this, but I think dropping XP for 8.0 is pretty reasonable. Even Windows Server 2k3 is EOL now, and we won't be releasing for a few months still. And it's not like 7.10 or whatever will stop existing. At the very least, if you can cook up a patch and people rally against it, we can apply it to HEAD and just say 8.2 will definitively remove it and that's that. But I imagine it would be fine for 8.0 as well. In short, you have my permission to use the launch codes, and nuke it from orbit. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10955#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#10955: GHC on windows does not resolve DLL dependencies -------------------------------------+------------------------------------- Reporter: Phyx- | Owner: Phyx- Type: bug | Status: patch Priority: normal | Milestone: 8.0.1 Component: Runtime System | Version: 7.10.2 (Linker) | Resolution: | Keywords: Operating System: Windows | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1340 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Tamar Christina <tamar@…>): In [changeset:"6e6438e15f33cb94ad6338e950e693f59d046385/ghc" 6e6438e1/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="6e6438e15f33cb94ad6338e950e693f59d046385" Allow the GHCi Linker to resolve related dependencies when loading DLLs Summary: GHCi does not correctly tell the Windows Loader how to handle dependencies to DLL's that are not on the standard Windows load path: 1. The directory from which the application loaded. 2. The current directory. 3. The system directory. Use the GetSystemDirectory function to get the path of this directory. 4. The 16-bit system directory. There is no function that obtains the path of this directory, but it is searched. 5. The Windows directory. Use the GetWindowsDirectory function to get the path of this directory. 6. The directories that are listed in the PATH environment variable. Note that this does not include the per-application path specified by the AppPaths registry key. The App Paths key is not used when computing the DLL search path. So what this means is given two DLLs `A` and `B` and `B` depending on `A`. If we put both DLLs into a new folder bin and then call GHC with: `ghc -L$(PWD)/bin -lB` the loading will fail as the Windows loader will try to load the dependency of `B` and fail since it cannot find `A`. *IMPORTANT* this patch drops XP Support. The APIs being used were natively added to Windows 8+ and backported to Windows 7 and Vista via a mandatory security patch (in 2011). This means that there is a chance that KB2533623 has not been installed on certain machines. For those machines I display a warning and temporarily expand the `PATH` to allow it to load. This patch will make sure that paths provided by the user with `-L` *and* the folder in which a DLL is found are added to the search path. It does so using one of two methods depending upon how new of a Windows version we are running on: - If the APIs are available it will use `addDllDirectory` and `removeDllDirectory`. The order of which these directories are searched is nondeterministic. - If the APIs are not available it means that we're running on a pretty old unpatched machine. But if it's being used in an environment with no internet access it may be the case. So if the APIs are not available we temporarily extend the `PATH` with the directories. A warning is also displayed to the user informing them that the linking may fail, and if it does, install the needed patch. The `PATH` variable has limitations. Test Plan: ./validate Added two new test T10955 and T10955dyn Reviewers: erikd, bgamari, thomie, hvr, austin Reviewed By: erikd, thomie Subscribers: #ghc_windows_task_force Differential Revision: https://phabricator.haskell.org/D1340 GHC Trac Issues: #10955 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10955#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler