Correct Windows libdir assumptions.

GHC and ghc-pkg make some pretty hard assumptions about where they're
running on Windows. They assume that they are always running from
`foo/bin/ghc.exe` and that to find the `lib` folder they can drop
`bin/ghc.exe` from the base path and append `lib`.

This is already false for the testsuite, which when testing thenbindist
 has one test which puts the binaries in `inplace/test   spaces`.

For some reason before this was either being skipped or mysteriously 
passing.
But as of `2017.02.11` our luck ran out.

the testsuite triggers a failure such as those in #13310

Let's soften the assumption and just check that `../lib` exists instead.

80 chars

Test Plan: ./validate

Reviewers: austin, erikd, bgamari

Reviewed By: bgamari

Subscribers: thomie, #ghc_windows_task_force

Differential Revision: https://phabricator.haskell.org/D3158

1 files changed, 10 insertions, 4 deletions

diff --git a/utils/ghc-pkg/Main.hs b/utils/ghc-pkg/Main.hs
index b350e084ac..3355838477 100644
--- a/utils/ghc-pkg/Main.hs
+++ b/utils/ghc-pkg/Main.hs
@@ -62,9 +62,7 @@ import qualified Data.ByteString.Char8 as BS
 -- mingw32 needs these for getExecDir
 import Foreign
 import Foreign.C
-#endif
-
-#ifdef mingw32_HOST_OS
+import System.Directory ( canonicalizePath )
 import GHC.ConsoleHandler
 #else
 import System.Posix hiding (fdToHandle)
@@ -1947,7 +1945,15 @@ unDosifyPath :: FilePath -> FilePath
 unDosifyPath xs = subst '\\' '/' xs
 
 getLibDir :: IO (Maybe String)
-getLibDir = fmap (fmap (</> "lib")) $ getExecDir "/bin/ghc-pkg.exe"
+getLibDir = do base   <- getExecDir "/ghc-pkg.exe"
+               case base of
+                 Nothing    -> return Nothing
+                 Just base' -> do
+                    libdir <- canonicalizePath $ base' </> "../lib"
+                    exists <- doesDirectoryExist libdir
+                    if exists
+                       then return $ Just libdir
+                       else return Nothing
 
 -- (getExecDir cmd) returns the directory in which the current
 --                  executable, which should be called 'cmd', is running