Skip to content
This repository has been archived by the owner on Feb 3, 2022. It is now read-only.

8.4.3 full addLibrarySearchPath error on Windows 10 #312

Closed
donya opened this issue Jul 4, 2018 · 3 comments
Closed

8.4.3 full addLibrarySearchPath error on Windows 10 #312

donya opened this issue Jul 4, 2018 · 3 comments
Assignees

Comments

@donya
Copy link

donya commented Jul 4, 2018

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.

@gbaz
Copy link
Contributor

gbaz commented Jul 4, 2018

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.

@gbaz gbaz added the defect label Jul 4, 2018
@randen randen self-assigned this Jul 6, 2018
@randen
Copy link
Contributor

randen commented Jul 6, 2018

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.
@randen randen added the Windows label Jul 7, 2018
@gbaz
Copy link
Contributor

gbaz commented Jul 9, 2018

This is resolved by a new release of the windows binaries: 23c0262 Thanks again for the very helpful report!

@gbaz gbaz closed this as completed Jul 9, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants