New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

8.4.3 full addLibrarySearchPath error on Windows 10 #312

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

Comments

Projects
None yet
3 participants
@donya

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

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Jul 4, 2018

Contributor

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.

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

This comment has been minimized.

Show comment
Hide comment
@randen

randen Jul 6, 2018

Contributor

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

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

Fix issue haskell#312: 8.4.3 full addLibrarySearchPath error on Windo…
…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

This comment has been minimized.

Show comment
Hide comment
@gbaz

gbaz Jul 9, 2018

Contributor

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

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 Jul 9, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment