GHC API 7.10 -> 8.0.1 (unusable due to missing or recursive dependencies)
Hello, I am migrating a use of the GHC API from GHC 7.10 to GHC 8.0.1 and have hit an issue whereby importing pre-compiled libraries spits out: package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0 though these packages are indeed in the sandbox and listed with ExposePackage in the packageFlags. To be clear, a variant of this code worked as expected under GHC 7.10. I have created a simplified test case to demonstrate the issue: https://github.com/agentm/testhsscript Here is the meat of the problem: * lib/Test.hs - contains a module importing Glob with some functions of no consequence https://github.com/agentm/testhsscript/blob/master/lib/Test.hs * test.hs includes the GHC API call to load the precompiled Test module from the cabal sandbox https://github.com/agentm/testhsscript/blob/master/test.hs * cabal file has two targets: Library and executable "test"- the executable uses the GHC API to load the pacakge "testhsscript" https://github.com/agentm/testhsscript/blob/master/testhsscript.cabal For reference, here is the GHC API invocation which works under GHC 7.10: https://github.com/agentm/project-m36/blob/master/src/lib/ProjectM36/AtomFun... I suspect I am missing something basic that has changed in GHC 8 and would very much appreciate any tips. Here is the failing result of attempting to load the testhsscript package: Setting up HscEnv Using binary package database: /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d/package.cache Using binary package database: /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0 package Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu is unusable due to missing or recursive dependencies: base-4.9.0.0 containers-0.5.7.1 directory-1.2.6.2 dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv filepath-1.4.1.0 transformers-0.5.2.0 transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N package ghc-paths-0.1.0.9-GIOnKzk0HmEBZ77Q1HsThK is unusable due to missing or recursive dependencies: base-4.9.0.0 package mtl-2.2.1-6qsR1PHUy5lL47Hpoa4jCM is unusable due to missing or recursive dependencies: base-4.9.0.0 transformers-0.5.2.0 package dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 package transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N is unusable due to missing or recursive dependencies: base-4.9.0.0 ghc-prim-0.5.0.0 transformers-0.5.2.0 loading package database /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d test: <command line>: cannot satisfy dlist: dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 (use -v for more information) Cheers, M
Hello A.M., In 8.0.1 package databases must be specified in the correct order, whereas in 7.10 they could be done in any order. This problem was fixed in 8.0.2, give it a try. Edward Excerpts from A.M.'s message of 2017-01-06 22:00:49 -0500:
Hello,
I am migrating a use of the GHC API from GHC 7.10 to GHC 8.0.1 and have hit an issue whereby importing pre-compiled libraries spits out:
package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0
though these packages are indeed in the sandbox and listed with ExposePackage in the packageFlags. To be clear, a variant of this code worked as expected under GHC 7.10.
I have created a simplified test case to demonstrate the issue:
https://github.com/agentm/testhsscript
Here is the meat of the problem:
* lib/Test.hs - contains a module importing Glob with some functions of no consequence https://github.com/agentm/testhsscript/blob/master/lib/Test.hs
* test.hs includes the GHC API call to load the precompiled Test module from the cabal sandbox https://github.com/agentm/testhsscript/blob/master/test.hs
* cabal file has two targets: Library and executable "test"- the executable uses the GHC API to load the pacakge "testhsscript" https://github.com/agentm/testhsscript/blob/master/testhsscript.cabal
For reference, here is the GHC API invocation which works under GHC 7.10:
https://github.com/agentm/project-m36/blob/master/src/lib/ProjectM36/AtomFun...
I suspect I am missing something basic that has changed in GHC 8 and would very much appreciate any tips.
Here is the failing result of attempting to load the testhsscript package:
Setting up HscEnv Using binary package database: /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d/package.cache Using binary package database: /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d/package.cache loading package database /home/agentm/Dev/testhsscript/.cabal-sandbox/x86_64-linux-ghc-8.0.1-packages.conf.d package testhsscript-0.1-CQQKGzp5pWwBmTnAldv1Hk is unusable due to missing or recursive dependencies: Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu base-4.9.0.0 package Glob-0.7.13-2PN6d9dpHzz7DHotD0T0wu is unusable due to missing or recursive dependencies: base-4.9.0.0 containers-0.5.7.1 directory-1.2.6.2 dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv filepath-1.4.1.0 transformers-0.5.2.0 transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N package ghc-paths-0.1.0.9-GIOnKzk0HmEBZ77Q1HsThK is unusable due to missing or recursive dependencies: base-4.9.0.0 package mtl-2.2.1-6qsR1PHUy5lL47Hpoa4jCM is unusable due to missing or recursive dependencies: base-4.9.0.0 transformers-0.5.2.0 package dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 package transformers-compat-0.5.1.4-G5tKvPrwhggJRvSwXNMs1N is unusable due to missing or recursive dependencies: base-4.9.0.0 ghc-prim-0.5.0.0 transformers-0.5.2.0 loading package database /opt/ghc/8.0.1/lib/ghc-8.0.1/package.conf.d test: <command line>: cannot satisfy dlist: dlist-0.8.0.2-GWAMmbX9rLg3tqrbOizHGv is unusable due to missing or recursive dependencies: base-4.9.0.0 deepseq-1.4.2.0 (use -v for more information)
Cheers, M
On 01/06/2017 10:37 PM, Edward Z. Yang wrote:
Hello A.M.,
In 8.0.1 package databases must be specified in the correct order, whereas in 7.10 they could be done in any order. This problem was fixed in 8.0.2, give it a try.
Thanks for the tip, Edward. That was it! Following https://ghc.haskell.org/trac/ghc/ticket/12485 to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.htm..., I read: "By default, the stack contains just the global and the user’s package databases, in that order." However, the order that works for me is: extraPkgConfs = const (localPkgPaths ++ [GlobalPkgConf]) so is the description flipped or is the stack head at the end of the list? In any case, it's rather confusing, though I recognize that the above sentence is not referring to the GHC API in particular. I now see that the wrong ordering caused me to be unable to load *any* packages from my sandbox. Thanks for the fix! Cheers, M
Hi A.M., It's very possible that the list in DynFlags are accumulated in reverse order to the flags that were provided. The manual is just talking about user provided flags. You may also be interested in https://downloads.haskell.org/~ghc/master/users-guide/extending_ghc.html#fro... Edward Excerpts from A.M.'s message of 2017-01-07 10:54:56 -0500:
On 01/06/2017 10:37 PM, Edward Z. Yang wrote:
Hello A.M.,
In 8.0.1 package databases must be specified in the correct order, whereas in 7.10 they could be done in any order. This problem was fixed in 8.0.2, give it a try.
Thanks for the tip, Edward. That was it!
Following https://ghc.haskell.org/trac/ghc/ticket/12485 to https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/packages.htm..., I read:
"By default, the stack contains just the global and the user’s package databases, in that order."
However, the order that works for me is:
extraPkgConfs = const (localPkgPaths ++ [GlobalPkgConf])
so is the description flipped or is the stack head at the end of the list? In any case, it's rather confusing, though I recognize that the above sentence is not referring to the GHC API in particular.
I now see that the wrong ordering caused me to be unable to load *any* packages from my sandbox.
Thanks for the fix!
Cheers, M
participants (2)
-
A.M. -
Edward Z. Yang