I am trying to cabal install yesod on my Windows machine. I have a relatively fresh install of the Haskell Platform. The cabal install failed, reporting that I need the sqlite3 C library in order to install "persistent", a package which Yesod relies upon.
cabal: Missing dependency on a foreign library:
* Missing C library: sqlite3
So I went to http://www.sqlite.org/download.html and grabbed both the C source and the precompiled binary. I tried using both, to no avail:
cabal install persistent --extra-lib-dirs=C:\Path\To\C\Source\Files
cabal install persistent --extra-lib-dirs=C:\Path\To\Binary
In both cases, I got the same result: it didn't work. :( What can I do to give cabal the C library it needs? (sqlite3 in this case)
So, facepalm. I didn't need the source, I didn't need the exe. I needed the dll.
Under the "precompiled binaries for Windows" section of the website mentioned in my question, I downloaded and extracted the zip file with sqlite3.def and sqlite.dll. Then I used
cabal install persistent --extra-lib-dirs=C:\Path\To\DllAndDef
The installation appears to have completed successfully. Afterwards, I did a cabal install yesod, which also appears to have completed successfully.
I suppose if I had put the dll somewhere magical, then I wouldn't have had to use the --extra-lib-dirs= option.
Related
I'm trying install tidal in command line this way:
cabal install tidal
but it ends with this message:
Warning: You asked to install executables, but there are no executables in
target: tidal. Perhaps you want to use --lib to install libraries instead.
Return of:
cabal install tidal --lib
is:
Resolving dependencies...
Up to date
If I check ghk-pkg list, there is no package tidal
...
Have somebody similar problem or what I'm doing wrong?
My environment is:
Windows 10 Education
Haskell 8.4.3
Cabal 3.2.0.0
Ghc 8.10.1
Thank you for help.
Like Stack for a longer time, Cabal-install does now (as of 3.2) not really install libraries anymore – in the sense of, change the computer's state so that GHC can access the library on it†. Both tools only install executables now. It used to do that for libraries too, but that was stopped with the now default Nix-style builds.
Now (and, really, also already before), the way to use a library is instead to just depend on it, and let Cabal figure out behind the scenes if it needs to be installed. I.e., you add a .cabal file to your .hs source file with build-depends: tidal in it. Then when you say cabal install ., it will first download and install the library before then using it for building your own executable.
†Of course both Stack and Cabal do technically speaking install libraries, just they don't globally register them. I.e., cabal knows where it has installed the library, but you're not really supposed to know about that. It's in the spirit of continuous integration: if your code builds now with the particular state of libraries you happen to have installed, that's not very reliable. If it builds with just those libraries that are explicitly listed in a project file, the chances are much better that future-you (or somebody else) will still be able to use your code on another computer without hours of figuring out what libraries to install first.
cabal install --lib tidal doesn't install the library binaries in a location managed by ghc-pkg. The binaries remain in the Cabal "store".
What it does is to create a plaintext GHC package environment file that is picked up by standalone invocations of ghc and ghci and tells them where to look for the extra libraries.
By default (as mentioned in the docs) this package environment file will be created at ~/.ghc/$ARCH-$OS-$GHCVER/environments/default and will be picked by ghc and ghci invocations made anywhere.
We can also supply an extra --package-env parameter to create the environment file in a local folder, which will only affect ghc and ghci invocations made in that folder. For example:
cabal install --lib --package-env . tidal
cabal projects themselves ignore environment files, as their package environments are constructed from the build-depends section of the cabal file for the sake of reproducibility. But environment files are useful for not having to create a cabal project in the first place, if you only need it for playing with the library in ghci, or if you are compiling simple programs using ghc only.
I'm trying to compile a Haskell source package as a dynamic library to be used with OCaml code. I tried using the --enable-shared option with cabal install on the .cabal file of the source, I got a Perhaps you haven't installed the "dyn" libraries for package 'zeromq4-haskell-0.6.5' error. After a little googling, I realised that the dependencies must also be compiled as dynamic libraries. I downloaded the source package for zeromq and tried installing the zeromq package with the --enable-shared option. This time I got a similar error with one of zeromq's dependencies. I tried doing this 4-5 times and get an error with a different dependency at each level.
Am I making a mistake here? How can I get all of the dependencies to install as dynamic libraries?
Thanks!
If you generally want to have shared libraries, you can permanently enable it in your .cabal/config:
shared: True
However, it will only affect libraries installed after that, so you may want to purge all libraries and start over again.
If this is just a one-shot, you may create a cabal sandbox just for that purpose:
cd yourlib
cabal sandbox init
cabal install --enable-shared
The result will be in the directory .cabal-sandbox.
I have decided to try to install gtk2hs on my Windows 8 (64 bit) machine. I am relying on the lastest Haskell Platform distribution.
So, I go on the wiki, and follow the instructions. I get gtk+ 32-bit distribution, version 2.24, in the all in one bundle. I unpack it correclty, set up PATH to point to gtk/bin, and create INCLUDE and LIB variables to point respectively to gtk/include and gtk/lib (this step does not seem necessary, but it can't hurt!)
I then verify all is in order by invoking
pkg-config --modversion gtk+-2.0
and the terminal happly chirps back
2.24.10
Great!
Then, I run cabal install
gtk2hs-buildtools
and that also goes well.
But then, when I run cabal install gtk, it complains that glib fails to install, because it can't find some C dependencies. I try to isolate the problem by running
cabal install glib
and get the following:
C:\Users\Federico>cabal install glib
Resolving dependencies...
Configuring glib-0.13.1.0...
Failed to install glib-0.13.1.0
Last 10 lines of the build log ( C:\Users\Federico\AppData\Roaming\cabal\logs\gl
ib-0.13.1.0.log ):
[1 of 2] Compiling Gtk2HsSetup ( Gtk2HsSetup.hs, dist\setup-wrapper\Gtk2HsS
etup.o )
[2 of 2] Compiling Main ( SetupMain.hs, dist\setup-wrapper\Main.o )
Linking dist/setup-wrapper\setup.exe ...
Configuring glib-0.13.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: gobject-2.0, gthread-2.0, glib-2.0, intl
This problem can usually be solved by installing the system packages that
provide these libraries (you may need the "-dev" versions). If the libraries
are already installed but in a non-standard location then you can use the
flags --extra-include-dirs= and --extra-lib-dirs= to specify where they are.
cabal: Error: some packages failed to install:
glib-0.13.1.0 failed during the configure step. The exception was:
ExitFailure 1
But this is utter crap! I KNOW the libraries are there. I can see them, in the gtk/bin folder! I re-check my path, and all is good. They are visible, in path. so is include, and lib. All of it. And yet, cabal complains it can't find them.
But this isn't the scariest bit yet...I download the 64-bit of the library, version 2.16...simply swap the two gtk folders...and now, cabal happly builds the whole thing! Of course, it's unsuable, because ghc on the plaftorm is 32-bit and the libraries are 64-bit, so ghc fails to link against it...but at least cabal was pleased.
I then remove glib, cairo, pango, gtk etc, and go about trying installing again, 2.16, 32-bit. And surely, cabal complains about C dependencies missing.
At this point, befuddled by this kafkian situation, I turn to the wisdom of stack overflow!
Is cabal trolling me? Are the error messages misleading? Or am I missing something obvious?
Thanks to all for the help!
If you are using 64 bit version of GHC, you want to use 64 bit version of gtk as well.
You can download it on this link. Scroll down a bit and download 2.x (not 3.x) all in one bundle, don't download 2.16:
http://www.gtk.org/download/win64.php
Above is no longer an option. You can try installing MSYS and than using MSYS console with pacman package manager to install gtk dev library on windows (I haven't tried it yet though). This pretty much sucks in my opinion.
When I build a Cabal project without a sandbox, Cabal uses existing libraries from my Haskell Platform installation. However, if I try to do the same inside a Cabal sandbox, Cabal forcibly rebuilds all my dependencies into the sandbox.
To save on build times and disk space, it'd be great to be able to instruct Cabal to use existing Haskell Platform libraries instead of rebuilding them. Is this possible?
Example (files in a gist):
executable blog
hs-source-dirs: .
main-is: Test.hs
build-depends: base >= 4.5 && < 5
, text
If I cabal build in the directory containing this .cabal file, my Test module gets built against the Haskell Platform version of text.
However, if I do the same in a sandbox:
cabal clean # (or alternatively clone an empty gist)
cabal sandbox init
cabal build
I get this:
$ cabal build
Package has never been configured. Configuring with default flags. If this
fails, please run configure manually.
Resolving dependencies...
Configuring install-test-0.1...
cabal: At least the following dependencies are missing:
text -any
If I now go and cabal install, the latest text library is built from scratch under my sandbox.
As per cabal-install bug #1695, this is currently not supported. It's something that may eventually be built, see multi-instance packages for more information.
If anyone's reading and cares, an alternative that should work for some users would be to share a single cabal sandbox among multiple projects. This way you could still keep your Haskell Platform installation separate from library installations you need during your development. More on that in An Introduction to Cabal sandboxes
I'm updating my yesod framework to the latest yesod 1.2 version. I've installed yesod-platform (painfully....had to manually delete old dependency....cabal hell), now I need to install yesod-bin and it should be done. However, after sudo cabal install yesod-bin I'm getting the following error.
Building yesod-bin-1.2.0...
Preprocessing executable 'yesod-ld-wrapper' for yesod-bin-1.2.0...
[1 of 1] Compiling Main ( ghcwrapper.hs, dist/build/yesod-ld-wrapper/yesod-ld-wrapper-tmp/Main.o )
Linking dist/build/yesod-ld-wrapper/yesod-ld-wrapper ...
/usr/bin/ld: cannot find -lHStar-0.4.0.1
/usr/bin/ld: cannot find -lHSoptparse-applicative-0.5.2.1
/usr/bin/ld: cannot find -lHSghc-paths-0.1.0.9
/usr/bin/ld: cannot find -lHSfsnotify-0.0.6
/usr/bin/ld: cannot find -lHShinotify-0.3.5
collect2: ld returned 1 exit status
Failed to install yesod-bin-1.2.0
cabal: Error: some packages failed to install:
yesod-bin-1.2.0 failed during the building phase. The exception was:
ExitFailure 1
According to this, I feel it may have something to do with privileges I'm not sure.
EDIT: So I only found the following two libraries.
/usr/lib/haskell-packages/ghc/lib/tar-0.3.2.0/ghc-7.4.1/libHStar-0.3.2.0.a
/usr/lib/haskell-packages/ghc/lib/ghc-paths-0.1.0.8/ghc-7.4.1/libHSghc-paths-0.1.0.8.a
I'm trying to update libghc-tar-dev to the newest version 0.4.0.1. However, 0.3.2.0 is the newest version on apt-get what are my options?
First, I'd check to see if you have the libraries libHStar, libHSoptparse-applicative, libHSghc-paths, libHSfsnotify and libHShinotify. If you installed the haskell platform using your distro's package manager, I suspect you'll find those libraries in /usr/local/lib/ghc-*.*.*/. For example, you might search for the first library using this command:
sudo find /usr/local/lib -name 'libHStar*'
If you don't have those libraries, then I think you can get them by using your distro's package manager to install the following:
libghc-tar-dev
libghc-optparse-applicative-dev
libghc-ghc-paths-dev
libghc-fsnotify-dev
libghc-hinotify-dev
If you already have those libraries, then you could adapt the fix suggested in your link:
sudo chmod a+r /usr/local/lib/ghc-*/libHS*
UPDATE:
The standard recommendation seems to be that you should always use your linux distro's package manager to install stuff, rather than using the cabal command directly. And if a package you want isn't available yet on your distro, request it. This approach is the safest, because all of the dependencies have been sorted out for you. The disadvantage is that you won't usually have the latest release. I see that there is a yesod package on Ubuntu. I have no idea if it contains yesod-bin (I'm not familiar with yesod), but if it does, that's the safest approach. The downside is that you will probably have to wipe out your cabal library and start from scratch (re-install haskell-platform, then yesod).
Another option, which seems to be the road you're on, is to use your package manager to install the haskell-platform, but after that use the cabal command to install any haskell-y stuff. You'll still use your package manager to install things that can't be installed using cabal (e.g., non-haskell stuff). If you do this, you can avoid a lot of cabal hell by never running cabal as root, and never letting your package manager do anything that can be done using cabal. The main disadvantage of this approach is that you have to deal with library dependencies yourself, as you've discovered. If you want to continue down this road, you might be able to get everything you need by switching to some development/test build for Ubuntu. Or you may have to get the correct versions of the libraries you need and manually install them.