I'm having some trouble getting all these tools to work together, and I would be interested to hear if someone has managed.
My main problem is the following: I have some external dependencies, which in my stack.yaml look like this:
nix:
enable: true
packages: [curl, postgresql94, zlib]
which are clearly provided by the nix system. When I run ghc-mod type Main.hs 39 19 on my current Main.hs I get the following:
EXCEPTION: types:
<command line>: can't load .so/.DLL for: /home/user/.stack/snapshots/x86_64-linux-nix/lts-7.15/8.0.1/lib/x86_64-linux-ghc-8.0.1/postgresql-libpq-0.9.2.0-IWEdPrPraPeE94ud73Ope3/libHSpostgresql-libpq-0.9.2.0-IWEdPrPraPeE94ud73Ope3-ghc8.0.1.so (libpq.so.5: cannot open shared object file: No such file or directory)
so it seems to be having trouble loading these external dependencies.
Any ideas how to proceed?
Related
I've been working on a project and recently I did a cabal update.
I usually roll into ghci like:
$ ghci -package-db ~/.cabal/store/ghc-8.10.7/package.db
After the update loading module in my project results in even the basic Haskell modules like System.Random or MonadIO fails with the following errors when trying to load my own module called ProcessIO:
ProcessIO.hs:50:1: error:
Could not load module ‘Data.IORef.MonadIO’
It is a member of the hidden package ‘monadIO-0.11.1.0’.
You can run ‘:set -package monadIO’ to expose it.
(Note: this unloads all the modules in the current scope.)
Locations searched:
Data/IORef/MonadIO.hs
Data/IORef/MonadIO.lhs
Data/IORef/MonadIO.hsig
Data/IORef/MonadIO.lhsig
I checked that maybe the .cabal file build-depends versions might have been altered, but the cabal package.db directory contains all the right versions of the dependencies in the .cabal file. For example the error above complains abot monadIO-0.11.1.0 being hidden however: in package.db/ we see the right version exists:
monadIO-0.11.1.0-0aec75273f3fef94783e211a1933f8ac923485a963be3b6a61995d4a88dd1135.conf
I should say I haven't looked at the package.db files before because everything simple worked so there may be something telling about the .conf file name that signals something is wrong.
Either way, can't build anything and I need some help!
EDIT: posting my default environments file ~/.ghc/x86_64-linux-8.10.7/environments/default in case it matters:
clear-package-db
global-package-db
package-db /home/surya/.cabal/store/ghc-8.10.7/package.db
package-id ghc-8.10.7
package-id bytestring-0.10.12.0
...
(Let me know if I need to share more of it... or less)
Am working through Real World Haskell and am trying to install regex-posix-0.95.2 from an untar[ed] package by simplying running
cabal install
I then see:
Text/Regex/Posix/Wrap.hsc:141:1: error:
Could not find module ‘Text.Regex.Base.RegexLike’
There are files missing in the ‘regex-base-0.93.2’ package,
try running 'ghc-pkg check'.
Use -v to see a list of the files searched for.
|
141 | import Text.Regex.Base.RegexLike(RegexOptions(..),RegexMaker(..),RegexContext(..),MatchArray)
Despite the fact that I can load this in ghci with
Prelude> :module Text.Regex.Base.RegexLike
Prelude Text.Regex.Base.RegexLike>
Prelude> import Text.Regex.Base.RegexLike(RegexOptions(..),RegexMaker(..),RegexContext(..),MatchArray)
Prelude Text.Regex.Base.RegexLike>
and see it in the module-system.
[warrick#warrick-pc regex-posix-0.95.2]$ ghc-pkg find-module Text.Regex.Base.RegexLike
/usr/lib/ghc-8.6.2/package.conf.d
regex-base-0.93.2
Why is this failing?
What are some more general tips and tricks when trying to debug cabal failures you'd recommend (as this is one instance of many issues I'm consistently having with Cabal)?
This is a linking issue. For example, some distributions like Arch use dynamic linking by default, without static libraries, but without additional configuration, cabal tries to link statically, which results in the kind of message you are seeing. For more information: https://wiki.archlinux.org/index.php/Haskell
When I try compiling my Haskell program with Stack, I get the following error:
Building executable 'fractal' for fractal-0.1.0.0..
[1 of 2] Compiling Main ( app/Main.hs, .stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1/build/fractal/fractal-tmp/Main.o )
<command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/8.2.0/../../../../lib/libtinfo.so (-lncursesw: cannot open shared object file: No such file or directory)
-- While building custom Setup.hs for package fractal-0.1.0.0 using:
/home/lorxu/.stack/setup-exe-cache/x86_64-linux-tinfo6/Cabal-simple_mPHDZzAJ_2.2.0.1_ghc-8.4.3 --builddir=.stack-work/dist/x86_64-linux-tinfo6/Cabal-2.2.0.1 build lib:fractal exe:fractal --ghc-options " -ddump-hi -ddump-to-file -fdiagnostics-color=always"
When I compile with GHC directly, it works fine, and libncursesw.so is present in /usr/lib. I'm on Void Linux. Any ideas where Stack is looking?
This looks like an issue with the bindist Stack has chosen for Void Linux - it normally guesses right, but it can cause issues on some distros. The tinfo6 variant tries to load libtinfo.so, since some distributions provide ncurses6 through that shared object file. You can try configuring the variant manually - you'll probably want standard. Stack will install a new GHC version if you do that, but it will change what shared object it tries to load for ncurses.
EDIT:
This was actually caused by an issue with GHC - if the distro links between the various ncurses files with a linker file, instead of an actual link, GHC won't follow it properly and instead complain that the file doesn't exist. The solution is to replace the linker file with a link to the target.
My haskell installation can not find bytestring module installed by operating system
$ ghci
GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help
Loading package ghc-prim ... linking ... done.
Loading package integer-gmp ... linking ... done.
Loading package base ... linking ... done.
Prelude> :m +Data.ByteString.Lazy
<no location info>:
Could not find module `Data.ByteString.Lazy'
It is not a module in the current program, or in any known package.
But I have installed this module using yum:
$ rpm -ql ghc-bytestring
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2
/usr/lib64/ghc-7.6.3/bytestring-0.10.0.2/libHSbytestring-0.10.0.2-ghc7.6.3.so
/usr/share/doc/ghc-bytestring
/usr/share/doc/ghc-bytestring/LICENSE
What is wrong?
If this is happening, you should be able to figure out more via ghc-pkg list. This could happen, for example, if the binary package provided by your software repository was broken; ghc-pkg list would report that. In general, either GHC is not looking for packages in /usr/lib64/ghc-7.6.3/ or else that directory has a package.cache which was not updated to reflect the new package.
One thing that could cause GHC to look in the wrong place is if there are multiple GHCs on the machine: for example if which ghc reveals /usr/local/bin/ghc then you probably compiled GHC from source at some point and its packages are occupying some /usr/local/lib/ghc-7.6.3/package.conf.d/ folder, while your repository has installed /usr/bin/ghc which is looking in the folder you want.
Anyway, fixes: if the package.cache file exists and has a valid entry for the file, then you can run ghc -package-conf /path/to/package.cache ... to add those packages to your executable. If you have further problems, ghc -v ... is a great resource for debugging "which version of that package is being used here?" types of problems.
If the package.cache file does not exist then you've got a bigger problem, and probably the easiest way to move forward is to look for a directory under /home which appears on ghc-pkg list. Install the required package to that directory and GHC should pick up on it even though it doesn't understand these bigger contexts. You could also start working with a cabal sandbox of local packages to your project.
Situation here is similiar to C++ you have libraries used during dynamic linking stage and header used for compilation. In Fedora packages like ghc-bytestring are only libraries without headers. To install headers I had to install ghc-bytestring-devel package.
An example on Fedora 24:
server.hs:7:8:
Could not find module ‘Data.Text’
Perhaps you meant Data.Set (from containers-0.5.5.1)
Locations searched:
Data/Text.hs
Data/Text.lhs
So change to user root, then:
What packages are there?
# dnf search ghc|grep text
ghc-text.x86_64 : An efficient packed Unicode text type
ghc-boxes.x86_64 : 2D text pretty-printing library
ghc-pango.x86_64 : Binding to the Pango text rendering engine
ghc-css-text.x86_64 : CSS parser and renderer
ghc-hgettext.x86_64 : Haskell binding to libintl
ghc-attoparsec.x86_64 : Fast combinator parsing for bytestrings and text
ghc-text-devel.x86_64 : Haskell text library development files
ghc-blaze-textual.x86_64 : Fast rendering of common datatypes
ghc-css-text-devel.x86_64 : Haskell css-text library development files
ghc-hgettext-devel.x86_64 : Haskell hgettext library development files
ghc-blaze-textual-devel.x86_64 : Haskell blaze-textual library development files
So what's installed?
# rpm --query ghc-text
ghc-text-1.1.1.3-3.fc24.x86_64
# rpm --query ghc-text-devel
package ghc-text-devel is not installed
So let's install the devel package.
# dnf install ghc-text-devel
Installed:
ghc-text-devel.x86_64 1.1.1.3-3.fc24
...and compilation succeeds after that.
I'm using Ubuntu 14.10 with GHC 7.6.3 and cabal installed via the Ubuntu package installer, and trying to use the Heap data structure, which I naively installed using:
cabal install heap
As soon as I started importing the library into my code, I got the following linking error:
...
Loading package primitive-0.5.0.1 ... linking ... done.
...
Loading package heap-1.0.0 ... linking ... done.
...
Loading package primitive-0.5.2.1 ... linking ... done
...
GHCi runtime linker: fatal error: I found a duplicate definition for symbol
hsprimitive_memset_Word32
whilst processing object file
/home/simon/.cabal/lib/primitive-0.5.2.1/ghc-7.6.3/HSprimitive-0.5.2.1.o
This could be caused by:
* Loading two different object files which export the same symbol
* Specifying the same object file twice on the GHCi command line
* An incorrect `package.conf' entry, causing some object to be
loaded twice.
GHCi cannot safely continue in this situation. Exiting now. Sorry.
This answer notionally explains what to do, but the instructions are not specific enough for me to follow.
How do I get Heap to use primitive-0.5.2.1 (I'm assuming that this lightly used library is the one that is out of date), or should I be doing something completely different?
One solution might be to specifically install an earlier version of heap:
cabal install heap-0.6.0
You might have to first unregister heap-1.0.0.
Another option is to blow away your ~/.ghc directory. Of course, you will have to reinstall cabal packages.
I think the best option is to start using cabal sandboxing for your projects.
Edit: heap-1.0.0 contains QuickCheck tests and thus brings in all of the QuickCheck dependencies. To install that version without QuickCheck, try this:
In a new directory, run cabal get heap-1.0.0
cd heap-1.0.0
Edit heap.cabal and remove the Build-Depends: line
Run cabal install