This question is the distilled solution of what others have helped me solved. The discussion can be found on this issue and this r/xmonad post.
I'm using Artix mainly with Pacman as a package manager. Today, after about a week, I've upgraded many packages and it ended up breaking XMonad.
This is the message I get from xmonad --recompile -v:
XMonad is recompiling and replacing itself another XMonad process because the current process is called "xmonad" but the compiled configuration should be called "xmonad-x86_64-linux"
XMonad will use ghc to recompile, because "/home/philippe/.xmonad/build" does not exist.
XMonad skipping recompile because it is not forced (e.g. via --recompile), and neither xmonad.hs nor any *.hs / *.lhs / *.hsc files in lib/ have been changed.
/home/philippe/.xmonad/xmonad-x86_64-linux: error while loading shared libraries: libHSxmonad-contrib-0.16-KKfUmtIonstICqbgIKQKYh-ghc8.10.4.so: cannot open shared object file: No such file or directory
I've tried a ton of solutions people mentioned on the internet — so far I've spent more than 3 hours trying to debug this —, among them, notably:
cabal install --lib xmonad-contrib, which had solved some issues I've had with XMonad in the past.
Removing and reinstalling Stack, GHC, Cabal, and XMonad itself.
Installing XMonad through Stack.
This ended up giving me the same error message, the difference is that I had to execute ~/.local/bin/xmonad --recompile -v instead.
Does anyone have an idea of how to solve this? I've had problems with upgrades of XMonad before, but never anything close to this — I love Haskell as a language, but its package management is one of the most disgusting, overcomplicated pieces of software I've ever experienced in my 10+ years of programming life.
If I end up cleaning up my system and managing everything through Stack, how do I compile XMonad through it? Using only Stack and then xmonad --recompile is giving me this error:
XMonad will use ghc to recompile, because "/home/philippe/.xmonad/build" does not exist.
xmonad: ghc: runProcess: runInteractiveProcess: exec: inappropriate type (Not a directory)
(I do have an ~/.xmonad/build/ folder by the way...)
I've finally made it work. The guys from the XMonad repo really helped, you can check out their help in this issue.
Roughly, what I did was:
Delete everything Haskell-related from my system.
Do this one carefully, use a lot of finds with the words haskell, stack, ghc, cabal, etc. Don't forget to use pacman -Rns and pacman -Q to uninstall everything that come from there first.
As some other users mentioned, you should absolutely not manage Haskell packages with both Pacman/AUR and Stack/Cabal. Choose one system and stick to it. Stack is probably the recommended one.
Install Stack directly with the script on its documentation.
Install GHC, XMonad, and XMonad-Contrib through Stack.
Create a build script for compiling XMonad with Stack:
#!/bin/sh
exec stack ghc -- \
--make xmonad.hs \
-i \
-ilib \
-fforce-recomp \
-main-is main \
-v0 \
-o "$1"jk
Add exec $HOME/.xmonad/xmonad-x86_64-linux to .xinitrc so it runs what was compiled with Stack previously.
Related
I'm building a Haskell 7.10 project that depends on tdsodbc.dll, using stack v1.7.1 on Windows, everything 64-bit. I have tdsodbc.dll in the lib folder of the project, and extra-lib-dirs: lib and extra-libraries: tdsodbc in the .cabal.
But when I compile, I get Missing C library: tdsodbc when stack runs cabal configure. I've tried putting extra-lib-dirs: [lib] in stack.yaml, and I can see from that configure command that it has put --extra-lib-dirs=C:\Users\Kevin\src\theproject\lib on the cabal configure command line, but still complains about it missing.
Now the weird part: If I remove ekg from the build-deps of the project (and remove the relevant imports etc.), the project builds just fine! I still have to copy the dll into .stack-work/dist/… to make it run, but why would ekg in build-deps stop cabal from being able to configure it?
I've tried the trick from Cannot get cabal to find the mpi library for haskell-mpi on Windows with putting c/Users/Kevin/src/theproject/lib in LIBRARY_PATH (there's no .a file to mv in my case, and no .h's), but that didn't help me. Only removing ekg has helped me so far. What could be causing this? The "solution" seems completely irrelevant to the problem :(
EDIT: I tried using plain Haskell Platform 7.10.3 (from https://www.haskell.org/platform/prior.html ), and that configured and built just fine. So the problem is just when cabal configure is called from stack.
I'm trying to use nix-shell as a #! wrapper for runghc, as suggested in the manpage. But it cannot find the libraries. Given the following example, cut-down from the manpage
#! /usr/bin/env nix-shell
#! nix-shell -i runghc -p haskellPackages.HTTP
import Network.HTTP
main = return ()
I get the following result:
[~:0]$ ./nixshelltest
nixshelltest:4:1: error:
Failed to load interface for ‘Network.HTTP’
Use -v to see a list of the files searched for.
[~:1]$
to my mind, that's exactly what nix-shell -p is to avoid.
Am I doing something wrong, missing the point, or is there a bug? This is both on a nixOS 17.03 host, and also a host running nix 17.09 on top of Ubuntu.
Thanks,
The environment that you're using to run the script is missing a step. It's got a GHC and a HTTP package, but the compiler doesn't know about the package.
The way GHC and library packages work in nix might be a little "inside out" from what you're expecting. You actually need to install a compiler that "depends on" all of the libraries you want, rather than simply installing the compiler and the library separately. The reason is that GHC is designed to have library packages added by modifying the file tree where GHC is installed. On a mutable file system with only a single system GHC install you would just modify GHC whenever a library was installed, but nix can't. Nix has to be able to install a frozen GHC that never changes, and potentially many of them.
So what happens instead is that you install a tiny wrapper which depends on the both the underlying "raw" GHC install and all of the libraries that you want to use. The wrapper then acts like an install of GHC that had those libraries registered, without actually needing to duplicate an entire GHC install. When you just install a library package on its own it just sits there inert, without any GHC being able to find it just by it existing.
In fact, the script you've shown here doesn't actually specify that it should have a compiler installed at all; it just asks for the HTTP library. When I tried your script I got command not found: runghc. The runghc is only working on your system because it happened to already be in your path when you ran this (perhaps because you have GHC installed in your profile?), and that GHC wasn't installed with the HTTP package and so can't see it. The nix-shell adding just the library to the environment doesn't help.
What you need to do instead is use this line:
#! nix-shell -i runghc -p "ghc.withPackages (ps: [ ps.HTTP ])"
You're not installing either ghc or HTTP directly; instead the ghc.withPackages function computes a nix package that installs a GHC wrapper that knows about the HTTP Haskell package. Under the hood this depends on a "raw" GHC with no additional libraries, and also on the HTTP library and will cause those to be installed too.
If you use lots of different Haskell environments (possibly via nix-shell scripts like this that each need a different set of libraries), then you will end up with a unique withPackages wrapper installed on your system for each combination of libraries you ever use. But that's okay because the wrappers themselves are tiny, and nix is able to share and reuse the underlying GHCs and library packages between all of those environments.
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.
again...
I'm messing around with profiling in GHC after recently starting to learn Haskell. I'm trying to use profiling to see how different implementations of functions vary in performance, for example using list comprehension instead of map. I'm trying to compile with the -prof flag but im getting the following output:
david#david-LinuxMint ~/Desktop/Sandbox/Haskell/a $ ghc --make Filt -prof
Filt.hs:1:1:
Could not find module `Prelude'
Perhaps you haven't installed the profiling libraries for package `base'?
Use -v to see a list of the files searched for
The program compiles fine with the -prof flag omitted. Anybody have any ideas where im going wrong? I've tried to find something on SO/internet but my Google-Fu is failing me? Cheers.
This is for Linux, Debian in particular, but I believe the OP is using Mint which I think might be a Debian variant.
You probably got base from the OS packaging system (Debian: APT), so you'll also want to get the profiling version of base from that same system. On Debian the hackage package "foo" is in the Debian package "libghc-foo-dev"[1]. The profiling version of "libghc-blah-dev" is in the Debian package "libghc-blah-prof".
Now, base is a little special. Those packages exist, but are "virtual"; they are listed in relationships, but are actually installed by (one or more) other real packages. In Debian virtual libghc-base-dev is provided by real package ghc and virtual libghc-base-dev is provided by real package ghc-prof.
So, install ghc-prof (or the Mint equivalent) and you'll be good, or at least move on the the next error.
Eventually, you'll end up downloading and building packages directly from hackage. You'll have to change your cabal settings to build the profiling versions of those libraries.
[1] If another Haskell compiler gets (back) into Debian, the "ghc" in "libghc" will change to a string suitable for that compiler.
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.