Haskell Platform 8.4.3 full (but not core) gives an error message the first time certain IO operations are run after starting ghci in a command prompt or in PowerShell. Here is an example transcript from a fresh installation of Haskell Platform 8.4.3 full (with no updates or other installations before starting ghci).
C:\Users\Owner>ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Random
Prelude System.Random> randomIO
ghc.exe: addLibrarySearchPath: D:\GitHub\haskell-platform\build\ghc-bindist\local\mingw\lib (Win32 error 3): The system cannot find the path specified.
-1268725123919045314
Prelude System.Random> randomIO
7646080844187952831
This happens for me on three different Windows 10 machines with the same path showing in the error. Operating systems were Windows 10 Pro 1803 and Windows 10 Home 1803. Default installation settings were used. In all cases, the referenced D:\GitHub\... folder has never existed. One machine never had anything Haskell-related on it in the past and another did not have a D:\ drive. Some IO operations from other libraries generate numerous identical errors in sequence.
The problem does not occur with the core version and the example above with System.Random behaves correctly after installing random-1.1. I on core, so presume it's one of the extra things in the full version causing the behavior.
The text was updated successfully, but these errors were encountered:
Thanks for the careful report and sorry for the problems!
I can confirm this issue. Looking at the conf file for random in /lib/package.conf.d I can see that it includes the d:\GitHub path in the library dirs, dynamic-library-dirs, and include-dirs.
This is certainly a build issue with the full windows platform that we'll need to sort out.
Entries from the build machine user's cabal config file are copied into the .conf files. We need to insulate this inadvertent pollution of the built packages. Note that this has only recently been an issue with the Haskell Platform.
To fix this for the future, when cabal is invoked during an HP build, we will set and use a default cabal config file.
Edit: Also, not specific to Windows 10
randen
added a commit
to randen/haskell-platform
that referenced
this issue
Jul 6, 2018
…ws 10
When cabal is invoked during an HP build, we will set and use
a default cabal config file.
* hptool/src/Target.hs
* Entries from the build-machine-user's cabal config file
are copied into the <package>.conf files. We need to
insulate against this inadvertent pollution of the built
packages. So, with each cabal invocation, specify a path
to a cabal config file to use. The first time cabal
runs, it will create this file with all defaults, and
that file will be used for all the other uses of cabal
during the HP build.
Haskell Platform 8.4.3 full (but not core) gives an error message the first time certain IO operations are run after starting ghci in a command prompt or in PowerShell. Here is an example transcript from a fresh installation of Haskell Platform 8.4.3 full (with no updates or other installations before starting ghci).
C:\Users\Owner>ghci
GHCi, version 8.4.3: http://www.haskell.org/ghc/ :? for help
Prelude> import System.Random
Prelude System.Random> randomIO
ghc.exe: addLibrarySearchPath: D:\GitHub\haskell-platform\build\ghc-bindist\local\mingw\lib (Win32 error 3): The system cannot find the path specified.
-1268725123919045314
Prelude System.Random> randomIO
7646080844187952831
This happens for me on three different Windows 10 machines with the same path showing in the error. Operating systems were Windows 10 Pro 1803 and Windows 10 Home 1803. Default installation settings were used. In all cases, the referenced D:\GitHub\... folder has never existed. One machine never had anything Haskell-related on it in the past and another did not have a D:\ drive. Some IO operations from other libraries generate numerous identical errors in sequence.
The problem does not occur with the core version and the example above with System.Random behaves correctly after installing random-1.1. I on core, so presume it's one of the extra things in the full version causing the behavior.
The text was updated successfully, but these errors were encountered: