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.
Related
I installed the timezone-series Haskell module using cabal install timezone-series-0.1.5.1.
I then defined a module named Main.hs that starts with:
import Data.Time.LocalTime.TimeZone.Series -- from timezone-series-0.1.5.1
when I run ghc Main.hs, GHC throws the following error:
/home/ubuntu/Main.hs:2:1: error:
Failed to load interface for ‘Data.Time.LocalTime.TimeZone.Olson’
I tried explicitly including the cabal directory in GHC's search path using:
ghc -i/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/ Main.hs
This resulted in the correct path being searched, but GHC is only looking for files ending in the suffix ".hs":
Locations searched:
...
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhs
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.hsig
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Series.lhsig
Cabal installed interface files instead however:
/home/ubuntu/.cabal/lib/x86_64-linux-ghc-8.0.2/timezone-olson-0.2.0-KqRNJj3zomR7zz2Yx6P5Oq/Data/Time/LocalTime/TimeZone/Olson.hi
From line 318 of GHC's source code it looks like GHC ignores "*.hi" files unless it is called in single-shot mode (with the -c flag). Is this correct? (See: https://github.com/ghc/ghc/blob/67a5a91ef5e61f3b3c84481d8a396ed48cd5d96e/compiler/GHC/Unit/Finder.hs)
How can I get GHC to import this module?
An help will be greatly appreciated!
My suggested ways of installing packages in order of my preference:
Make a cabal package and add timezone-series you want to install to the build-depends field as described in the cabal manual.
Use the experimental cabal-env tool to basically automate the process of point 3 below, but then with the global environment. This makes a new build-plan every time you install a new package, so it is like removing the package environment and building it again with all the old packages and the new package added to it. You can add specific constraints like this: cabal-env "timezone-series == 0.1.5.1".
Install a package into local package environment with cabal --package-env . --lib timezone-series. You can add as many packages as you want after the --lib option to install more than one package. If you later want to use a different set of packages simply remove the .ghc.environment.* file that is generated and rerun the installation with a new set of packages. GHC will automatically use these package environment files that are in the current or parent directories. You can specify specific constraints with the --constraint option like this: --constraint "timezone-series == 0.1.5.1".
Use cabal install --lib timezone-series to install it directly into the global environment (~/.ghc/x86_64-linux-8.0.2/environments/default), this will fail if a conflicting package was installed earlier. When you run into errors you can remove that package environment and try again.
Finally, I want to note that GHC 8.0.2 is quite old, so I would advise you to upgrade if you don't have a specific reason for using that version.
I put this in a file (see bottom) and got the following error when loading it in ghci (i.e. start ghci then :l file):
7:13: error:
• Couldn't match expected type ‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph:Network.URI.URI’
with actual type ‘Network.URI.URI’
NB: ‘Network.URI.URI’
is defined in ‘Network.URI’
in package ‘network-uri-2.6.1.0#network-uri-2.6.1.0-80FpvaNUTSDFCPv0sSze40’
‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph:Network.URI.URI’
is defined in ‘Network.URI’
in package ‘network-uri-2.6.1.0#network-uri-2.6.1.0-7BN1tbB3iHQ2XgvmqLAYph’
Have I somehow installed two slightly different versions of network-uri, or what is this? How do I resolve it?
I've hardly used cabal but tried cabal install --reinstall network-uri, went fine but problem persists.
File contents:
import Network.HTTP
import Network.URI (parseURI)
import Data.Maybe (fromJust)
myRequestURL = "http://www.virginia.edu/cgi-local/ldapweb"
myRequest :: String -> Request_String
myRequest query = Request {
rqURI = fromJust $ parseURI myRequestURL
, rqMethod = POST
, rqHeaders = [ mkHeader HdrContentType "text/html"
, mkHeader HdrContentLength $ show $ length body ]
, rqBody = body
}
where body = "whitepages=" ++ query
main :: IO ()
main = do
response <- simpleHTTP $ myRequest "poon"
putStrLn ""
EDIT Re-installed haskell-platform. After this, ghc-pkg list reports all packages to be under (?) /usr/lib/ghc/package.conf.d, and the program I tried to copy loads just fine.
EDIT 2 After running cabal install some-pkg, ghc-pkg list reports that the newly installed stuff is in another directory. Indeed, ~/.cabal/config specifies install dirs for user, as well as install dirs for global. How is all this supposed to be managed properly?
GHC understands the concept of package databases. Cabal manages multiple package databases. There's a system package database, and a user package database. When you compile something with Cabal V1, it uses the union of these package databases. This is a bit of a time bomb, because, as you see, GHC does not like it when you have multiple of the same package. When you issued cabal install network-uri, cabal decided to install one copy of that package into your user database, though you already had one in the system database. When you tried to use ghc, it picked up on the two copies and got confused. Because cabal does not support removing packages, your Haskell installation was pretty much borked, and you reinstalled. I believe you could have done a more conservative rm ~/.ghc, or, had you been really adventurous, used the low-level ghc-pkg command to edit the package database.
Now that you've reinstalled the Platform, I would heavily recommend never using cabal install again. It's old, it's broken, cabal itself tells you not to use it. If you're using the Platform, I think it has stack in it, which is a different build manager, based on Cabal, which is not prone to this kind of breakage. Or, you can just stick to the V2 series of cabal commands, which is what I prefer.
Cabal V2 does not directly support your usecase, where you install a package globally and compile a program against it. This is because doing so is fundamentally broken: global package databases really just don't work for GHC. What Cabal V2 does is install packages into your home directory, ~/.cabal/store. You then have to explicitly tell it which packages you want, and it will construct a package database that contains each required package, without any wonkiness. You can get a REPL with a certain set of packages by issuing (this will take you to a temporary directory; you may need to :cd yourself back.)
cabal v2-repl -b network-uri -b package2 -b etc
If you want to actually compile files with ghc with a set packages, you have to actually define a package with a .cabal file. Here's a stub .cabal file:
name: temporary-pkg
version: 0.0.0.0
build-type: Simple
cabal-version: >=2.0
executable main -- if there is no Main, say "library" instead of "executable <name>"
default-language: Haskell2010
main-is: Main.hs -- only valid in executable stanzas
hs-source-dirs: src -- source files go here
build-depends: base, network-uri, package2, etc -- packages go here
Create and enter a directory, place that in temporary-pkg.cabal, place your sources in src/, and you can issue stuff like cabal v2-build and cabal v2-repl and cabal v2-exec main, etc. cabal will go off and install dependencies from Hackage into ~/.cabal/store as needed. cabal v2-install is therefore not that useful here. In general, v2-installing libraries is unnecessary, but v2-installing packages with executables is useful. Again, for hygiene reasons, you have to list all the packages you are importing from, but you don't need to list their dependencies or anything insane like that.
Cabal V2 still doesn't support uninstalling packages, though the point is that should not be necessary. However, if you find ~/.cabal/store getting too large for your liking, you can just nuke it, and should be built back up as packages are requested.
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
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
I'm currently trying to use pandoc (as a Haskell module, not as a program) to convert MediaWiki text to other formats.
Let's assume this program:
import Text.Pandoc.Readers.MediaWiki
main = do print "foo"
When using runghc to run it, I get the following error message:
pandock.hs:1:8:
Could not find module `Text.Pandoc.Readers.MediaWiki'
Use -v to see a list of the files searched for.
My first assumption was that pandoc was either not installed or incorrectly installed. Therefore I reinstalled it with --force-reinstalls
$ cabal install pandoc --reinstall
[...]
In order, the following will be installed:
pandoc-1.12.3.1 (reinstall) changes: old-time-1.1.0.1 added
[...]
[32 of 55] Compiling Text.Pandoc.Readers.MediaWiki ( src/Text/Pandoc/Readers/MediaWiki.hs, dist/build/Text/Pandoc/Readers/MediaWiki.o )
[...]
Installing library in
/home/uli/.cabal/lib/x86_64-linux-ghc-7.6.3/pandoc-1.12.3.1
Installing executable(s) in /home/uli/.cabal/bin
Registering pandoc-1.12.3.1...
Installed pandoc-1.12.3.1
The output of runghc -v pandock.hs is quite long, I assume the relevant part is:
*** Chasing dependencies:
Chasing modules from: *pandock.hs
pandock.hs:1:8:
Could not find module `Text.Pandoc.Readers.MediaWiki'
Locations searched:
Text/Pandoc/Readers/MediaWiki.hs
Text/Pandoc/Readers/MediaWiki.lhs
Failed, modules loaded: none.
However, both ~/.cabal/lib/x86_64-linux-ghc-7.6.3/pandoc-1.12.3.1/Text/Pandoc/Readers/Mediawiki/MediaWiki.hi and ~/.cabal/bin/pandoc exist. How can I make GHC properly recognize the cabal-installed package?
Any help will be appreciated!
When trying to reproduce this issue on other computers, only 2 out of 5 computers had this issue. On both of them I installed cabal packages in about the same way and order.
In retrospect I assume this issue arose because of some broken packages wreaking havoc:
$ ghc-pkg check
There are problems in package feed-0.3.9.2:
dependency "xml-1.3.13-dd52b1688e97a3c6cd0aa48dba7b153e" doesn't exist
There are problems in package hxt-9.3.1.3:
dependency "network-2.4.2.2-ea77cdf1bc747bc58308fdeb52745c4d" doesn't exist
There are problems in package hspec-1.8.1.1:
dependency "QuickCheck-2.6-409fcc32c191cd6e04afdebb15869820" doesn't exist
There are problems in package quickcheck-io-0.1.0:
dependency "QuickCheck-2.6-409fcc32c191cd6e04afdebb15869820" doesn't exist
There are problems in package regex-compat-0.95.1:
dependency "regex-base-0.93.2-2023953b859e6f91efe89733d2ef5421" doesn't exist
There are problems in package regex-posix-0.95.2:
dependency "regex-base-0.93.2-2023953b859e6f91efe89733d2ef5421" doesn't exist
There are problems in package hxt-9.3.1.2:
dependency "network-2.4.2.2-ea77cdf1bc747bc58308fdeb52745c4d" doesn't exist
The following packages are broken, either because they have a problem
listed above, or because they depend on a broken package.
feed-0.3.9.2
hxt-9.3.1.3
hspec-1.8.1.1
quickcheck-io-0.1.0
regex-compat-0.95.1
regex-posix-0.95.2
hxt-9.3.1.2
MissingH-1.2.0.2
yesod-test-1.2.1
Note that neither pandoc nor yaml (I installed it after asking the question and had the exact same issues as with pandoc) are listed there.
For users also having a similar problem, please ensure:
The package is installed and you're not inside any sandbox where the package is not installed.
In the directory where you're executing the test script, ensure that there is no Text/Pandoc folder (or equivalent, depending on the package causing the problem
Run your test script with runghc -v to check if it searches the proper directory
ghc-pkg list lists your package as installed, and no packages are broken (use ghc-pkg check to check)
I solved my problem by renaming ~/.cabal and ~/.ghc. Note that I did this lacking a proper solution, I think you should only do this as a last resort.