Mark H Weaver <m...@netris.org> writes: > Given that it's using #ifdef to detect this, I'd expect the result to > depend only on the _headers_ being used to compile, and not the actual > kernel running the build. Is that right? If so, this doesn't explain > why it works for Ricardo but not for Andreas and Hydra. > > Note that on our 'master' branch we are using Linux-libre-4.4 kernel > headers, but on 'core-updates' we're using 4.9 kernel headers.
FWIW, I only tried to build ghc-resourcet on the master branch, not on core-updates. > I suppose if one reads the error message literally: > > Control/Monad/Trans/Resource/Internal.hs:302:10: error: > • Could not deduce (MonadBase IO (Strict.StateT s m)) > arising from the superclasses of an instance declaration > from the context: MonadResource m > bound by the instance declaration > at Control/Monad/Trans/Resource/Internal.hs:302:10-63 > • In the instance declaration for > ‘MonadResource (Strict.StateT s m)’ > > "Could not deduce" might be interpreted to include the case where we > failed for lack of sufficient memory. They might have written the code > to catch any error at all, including out of memory errors, and report > the failure with this error message. I think that’s a misunderstanding. The cause for the error is earlier when it complains that some packages depend on different versions of the “transformers” package. “StateT” is a monad transformer. I think that “ghc-pkg” fails, which leads to some other version of the transformers package (maybe a default included with GHC) to be used. In the case where ghc-pkg does not fail (as on my laptop) the proper version is used, so there are no problems finding the expected instances. -- Ricardo GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC https://elephly.net
