I am trying to build and run a copy of the Hackage server https://github.com/haskell/hackage-server. I followed the instructions here https://github.com/haskell/hackage-server/wiki and also the instructions in the readme. Whichever I try, when trying to build with ghc 7.8.4 and cabal 1.22 I receive the following error:
Preprocessing executable 'hackage-server' for hackage-server-0.5.0...
Main.hs:40:8:
Could not find module ‘Network.URI’
It is a member of the hidden package ‘network-uri-2.6.0.1’.
Perhaps you need to add ‘network-uri’ to the build-depends in your .cabal file.
It is a member of the hidden package ‘network-2.4.2.3’.
Perhaps you need to add ‘network’ to the build-depends in your .cabal file.
I have also tried using the latest Haskell Platform, and I get the same failure message.
I'm trying to work out if this is a bug in the current master branch of hackage-server or if it is something to do with the way I installed ghc or cabal.
EDIT: I've tried again with the Ubuntu 14.04 repo haskell-platform (ghc 7.6.3, cabal 1.16) and the same error happens.
network-uri was split from network a while ago, but it looks like Hackage hasn't been updated with that change.
As a workaround, open hackage-server.cabal and add these lines to build-dependencies:
network >= 2.6,
network-uri >= 2.6
That should get it working again.
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 add the new llvm path to cabal to build with -fllvm option because I receive the error that it can't see the newer version:
<no location info>: error:
Warning: Couldn't figure out LLVM version!
Make sure you have installed LLVM 5.0
I have LLVM 5 installed under this path: /usr/local/Cellar/llvm#5/5.0.2/bin/. I need to somehow tell this to cabal but I can't find where to do this. In stack there is settings file under the installed ghc, but what is the wright way to do this for cabal?
I would start with
export PATH=/usr/local/Cellar/llvm#5/5.0.2/bin/:$PATH
cabal install
and see if that works.
I don't see any mention of options to set the LLVM path in the GHC user guide or the --with-PROG section of cabal configure --help. It certainly seems like a reasonable flag to add to cabal. The GHC guide only mentions finding it on PATH.
Recently I was trying to install llvm-general-3.5.1.0 package.. for about a week. Basically I am getting this error: link. My situation is identical. Windows 10, ghc 7.10.2, cabal 1.22.4.0. I installed llvm 3.5.2 from sources with cmake and everything went fine. In llvm/lib directory I have *.lib files (eg. LLVMAnalysis.lib).
But somehow cabal can't see those libraries and gives this frustrating error:
Configuring llvm-general-3.5.1.0...
setup.exe: Missing dependencies on foreign libraries:
* Missing C libraries: LLVMLTO, LLVMObjCARCOpts, LLVMLinker, LLVMipo,
LLVMVectorize, LLVMBitWriter, LLVMCppBackendCodeGen, LLVMCppBackendInfo,
LLVMTableGen, LLVMDebugInfo, LLVMOption, LLVMX86Disassembler,
LLVMX86AsmParser, LLVMX86CodeGen, LLVMSelectionDAG, LLVMAsmPrinter,
LLVMX86Desc, LLVMX86Info, LLVMX86AsmPrinter, LLVMX86Utils, LLVMJIT,
LLVMIRReader, LLVMAsmParser, LLVMLineEditor, LLVMMCAnalysis,
LLVMMCDisassembler, LLVMInstrumentation, LLVMInterpreter, LLVMCodeGen,
LLVMScalarOpts, LLVMInstCombine, LLVMTransformUtils, LLVMipa, LLVMAnalysis,
LLVMProfileData, LLVMMCJIT, LLVMTarget, LLVMRuntimeDyld, LLVMObject,
LLVMMCParser, LLVMBitReader, LLVMExecutionEngine, LLVMMC, LLVMCore,
LLVMSupport
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.
I really want to use this package on my Windows, but nothing seems to work (I tried everything like --extra-lib-dirs and compiled also with MinGW and VS - the same problem).
I can't accept the fact that it won't install. I mean, there must be some way to fix Setup.hs from this cabal package or something. Does anyone have an idea what can be wrong with cabal in this case and how can I try to workaround this? I don't know how exactly cabal works, maybe someone with this knowledge will have an idea? Or maybe there is a way to do this without cabal?
Ok, i've managed to build it and, i think, found the root of the issue.
First, steps to build:
Get the MinGW. My installation of MinGW has gcc 4.8.
Get 32-bit MinGHC.
Compile LLVM 3.5 with MinGW's gcc and install it somewhere.
Copy contents of MinGW installation directory into MinGHC Install
Dir\ghc-7.10.2\mingw, replacing conflict files.
In the command line set your PATH so it has haskell toolset from
MinGHC (i recommend using switch .bat scripts) and llvm-config.exe.
Get the llvm-general package source either using cabal fetch or
downloading via browser from hackage.
Replace cc-options: -std=c++11 line of llvm-general.cabal with
cc-options: -std=gnu++11.
Finally, cabal configure and cabal build should work.
I have been changing my build environment many times, so if this doesn't work for you let me know, i probably forgot something.
Now let's go into details.
What we thought is a bug of cabal is not, actually. The problem is that both stack and MinGHC (and Haskell Platform, i guess) use quite old gcc - 4.6. This gcc has even two defects:
It doesn't support -std=c++11 and LLVM 3.5 can't be built using it.
As a consequence, this gcc can't be used by ghc when compiling
llvm-general, because it can't parse LLVM headers properly.
Even if it could, its linker can't link against LLVM libs compiled by
MinGW using gcc 4.8. This is why cabal was telling you it
couldn't find LLVM libs. I've hacked Setup.hs so that it wouldn't
look for these libs, but pass -lLLVMSomething to linker via -pgml
ghc option. This lead to clear error message:
ld.exe: ignoring libLLVMSupport.a ...
ld.exe: can't find -lLLVMSupport
So, the cabal was actually finding these libs, but was dropping them because they couldn't be linked to.
Ideally, the solution would be to update mingw distribution used by stack/MinGHC. But as a workaround you can just replace old gcc with new one.
Finally, -std=gnu++11 is used because current MinGW release is affected by this bug, which prevents compilation of c++ bits of the package. Whew, that was a long way.
I am trying to install Haskell Platform 2014.2.0.0 from source on Red Hat Enterprise Linux 6.5. I have a functional install of Haskell Platform 2012.4.0.0 and GHC 7.4.2 from two years ago, plus a recently-installed Haskell Platform 2013.2.0.0 and GHC 7.6.3 from JustHub.
I've built GHC 7.8.3 from source, but it keeps coming up with seven failures in the test suite. I have no idea if these test failures are innocuous or not. (The test failures are not relevant to my question, but they may become significant later.)
I unpack the source tarball of 2014.2.0.0, read the README. It says that the way to build this iteration of Haskell is with a shell script, which is invoked:
./platform.sh $PATH_TO_GHC_BINDIST_TARBALL
I don't have a GHC binary distribution tarball. So far as I am able to tell, there is no binary distribution tarball of GHC 7.8.3 for any version of Red Hat Enterprise Linux. I have a built GHC 7.8.3. How do I tell platform.sh -- or whatever is underneath it -- that there is no tarball, and it should just use what's in $PATH? Alternately, how do I pack up my existing install of GHC 7.8.3 so that platform.sh will accept it?
The built GHC does not have a 'cabal' command, so the cabal commands in platform.sh are falling back to $PATH, which I can configure to be either of the other installed versions (2013.2/7.6.3 or 2012.4/7.4.2). It doesn't seem to make a difference: neither one recognizes 'cabal --sandbox'. Both result in complaints that I should run 'cd hptool ; cabal install --only-dependencies', which I've done, repeatedly. platform.sh never gets past that point.
If I run the commands in platform.sh by hand, I get to 'cd hptool; cabal build', which errors out: "cabal-1.16.0.2: Run the 'configure' command first.". But there is no 'configure' command available in the hptool directory.
I'm now stuck. How do I build Haskell Platform 2014 on RHEL 6?
You need to use your GHC sources to make your own "bindist." Directions at https://ghc.haskell.org/trac/ghc/wiki/MakingReleases
I managed to get Haskell Platform installed, and functional. I ended up abandoning platform.sh and just hand-installed all the packages in the Haskell Platform tarball -- and their dependencies -- with manual cabal commands. Along with the broken platform.sh, I ran into many problems on the way.
The ones that I remember:
platform.sh will never succeed if you have the stock Haskell Platform 2013 or previous installed. It wants a cabal that recognizes the '--sandbox' option, and cabal 1.18 doesn't know that option. You must have a newer cabal installed than Haskell Platform 2013 provides. (GHC 7.4 or 7.6 appears to be fine, though.)
I had an existing .cabal and .ghc directory, which had incompatible builds and/or versions of various packages. I deleted both directories numerous times while testing things.
cabal install --global behaves rather differently from the default cabal install --user. .cabal contained something useful after I did 'cabal install cabal-install'. It took two or three tries at that to figure out where the new cabal binary went.
ghc and cabal pick up new libraries in .ghc and .cabal, but not new binaries.
Neither GHC nor cabal install default to --enable-shared, except when something wants it. I had to go rebuild everything before that -- all the way back to GHC 7.8.3 itself -- with --enable-shared once that happened.
haddock is ridiculously tightly bound to the version of GHC it was built with. I had to rebuild it to get --enable-documentation to work for anything built with GHC 7.8.3.
The test packages and the text package are so tightly integrated that they have circular dependencies if you try to do 'cabal install text --enable-tests'. Even after installing the most recent version of text and the test packages, cabal still wouldn't run the text test suite, so I gave up and installed text without testing it.
My default environment includes 'LC_ALL=C'. This trips a known bug in cabal -- apparently in all versions -- that breaks some package builds. To work around it, I had to shift it to 'LC_ALL=en_US.utf8'. I have no idea if the packages affected will work if you have LC_ALL, or any of the other locale variables such as LANG or LC_<anything else>, set to C.
cabal install --global is terribly inconsistent about where packages get stored. We split out individual packages into their own subdirectories, and then build a symlink tree in a known place out of all those subdirectories. So ghc is in its own subdirectory of /usr/sup/ghc-7.8.3; Haskell Platform is in another subdirectory, /usr/sup/haskell-platform-2014.2.0.0. I consistently used --prefix=/usr/sup/haskell-platform-2014.2.0.0 on every 'cabal install' command, but even then, some libraries ended up in /usr/sup/ghc-7.8.3.
Both GHC and Haskell Platform have a dictionary of what's built and where it is -- perhaps as a workaround for the install location inconsistency -- in /usr/sup/ghc-7.8.3/lib/ghc-7.8.3/package.conf.d/package.cache. If that package dictionary isn't world-readable, ghc breaks. What it should do is look at the actual file structure to find things. Given that ghc breaks if the dictionary isn't available, the file shouldn't be called 'cache', as a cache miss shouldn't cause catastrophic failure. Perhaps rename it to 'package-mandatory-dictionary'?
Ultimately, it all installed, but I have to wonder about the damage I did from so much banging my head on the wall.
I've installed ghc 6.12.3, and then the Haskell Platform. I'm trying to compile a test program:
$ ghc test.hs
test.hs:3:0:
Failed to load interface for `Bindings':
Use -v to see a list of the files searched for.
so, naturally, I do
cabal install Bindings
Which works fine, and places the package in ~/.cabal/lib/bindings-0.1.2 The problem is, that when I go to compile again with ghc, it still doesn't find the package I've installed with cabal.
compiling in verbose mode gives:
ghc -v test.hs
Using binary package database: /home/ludflu/ghc/lib/ghc-6.12.3/package.conf.d/package.cache
Using binary package database: /home/ludflu/.ghc/x86_64-linux 6.12.3/package.conf.d/package.cache
As suggested by another stackoverflow user, I tried:
ghc-pkg describe rts > rts.pkg
vi rts.pkg # add the /home/ludflu/.cabal/lib to `library-dirs` field
ghc-pkg update rts.pkg
But to no avail. How to I add the .cabal to the list of package directories to search?
Thank you!
You can check which packages are installed with ghc-pkg list. It may be that you need to either specify the packages to ghc with -package <pkgname> or I believe adding --make to will trigger a chasing down of dependencies, including packages.
Edit: the bindings package is obsolete indeed, see the hackage page. This isn't a package management problem, the only module available is Bindings.Deprecated, which you are perfectly able to load, even though it is an empty module. I believe the relevant parts have been broken out into bindings-<module>, so if you want the bindings functionality you should look to those packages.
http://www.haskell.org/haskellwiki/Cabal-install
One thing to be especially aware of, is that the packages are installed locally by default by cabal, whereas the commands
runhaskell Setup configure
runhaskell Setup build
runhaskell Setup install
install globally by default. If you install a package globally, the local packages are ignored. The default for cabal-install can be modified by editing the configuration file.
I was getting the same error with the runhaskell command. I used the cabal in the directory that had the .cabal file and was able to resolve the error.