Skip to content
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

Cannot build Serialise.hs with GHC 8.10.4 #24

Closed
jwiegley opened this issue Jul 14, 2021 · 6 comments
Closed

Cannot build Serialise.hs with GHC 8.10.4 #24

jwiegley opened this issue Jul 14, 2021 · 6 comments

Comments

@jwiegley
Copy link

Using the latest nixpkgs-unstable and GHC 8.10.4, I get the following error during compilation:

[49 of 57] Compiling IC.Serialise     ( src/IC/Serialise.hs, dist/build/IC/Serialise.o, dist/build/IC/Serialise.dyn_o )

src/IC/Serialise.hs:25:1: error:
    Could not find module ‘System.Random.Internal’
    Use -v (or `:set -v` in ghci) to see a list of the files searched for.
   |
25 | import System.Random.Internal (StdGen(..))
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Pinging @nomeata

@nomeata
Copy link
Contributor

nomeata commented Jul 15, 2021

Hmm, that rings a bell, maybe I addressed that in one of the PRs already? Let me check...

Maybe the whole Serialize.hs module should be removed again. This was created for the use of ic-ref as an emulator in dfx (dfx start --emulator), where @hansl said that it’s important that the state can be persisted. I was never convinced, and I think Hans wants to write a separate emulator anyways. Hans?

I can’t find the branch where I tried to address this, if it ever existed. One solution is certainly to continue using an older version of random, where StdGen is not abstract. Another is to use the splitmix library directly, and store (Word64, Word64) in the state, and use seedSMGen' and unseedSMGen to produce the SMGen.

Something else must have stopped me while I tried to fix this back then. Maybe the problem with building rust on the latest nixpkgs.

@nomeata
Copy link
Contributor

nomeata commented Jul 15, 2021

Ah, I thought PRs #11 or #19 would actually upgrade GHC as well, but it seems that 8.4 is still used there. Let’s see what I can do.

@nomeata
Copy link
Contributor

nomeata commented Jul 15, 2021

Ok, something is odd. We have

  build-depends: random >= 1.2

and the only version of random with that constraint is 1.2.0 which exports System.Random.Internal.

@nomeata
Copy link
Contributor

nomeata commented Jul 15, 2021

Hmpf. That was a relative long time to find out that I can’t reproduce this. On current master, with cabal.project.freeze removed, I can run

~/dfinity/ic-hs $ cabal build -w ghc-8.10.4 

just fine.

@jwiegley, what revision are you on, what changed did you make, and what is your precise command?

@nomeata
Copy link
Contributor

nomeata commented Jul 15, 2021

See #25 for my freeze file

@jwiegley
Copy link
Author

Long story short, my apologies for wasting your time. My nixpkgs uses random 1.2, but somehow it's pulling in 1.1, so it's a problem on my side to be figured out. Thank you for looking into it!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants