libgmp.so not found

[istathar]

Attempting to use the generic Linux package (yes, I get that it's 0.0.0) it failed to be able to use the downloaded GHC with

    <command line>: can't load .so/.DLL for: libgmp.so (libgmp.so: cannot open shared object file: No such file or directory)

I did notice that the compiler you grab is https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.xz which suggests that its for a Debian based distro. I'm guessing they have a symlink by that name. On the other prominent distro family, there is indeed no /usr/lib64/libgmp.so. As a hack, I sudo'd up and added a symlink on a Fedora 22 system, and stack was then able to continue and do its thing.

Not sure how you work around that, other than whatever it is thinking that libgmp.so is going to exist needs to be told to look for something more specific, say libgmp.so.10 which is , after all, what it's ABI'd against.

Obviously I could have used ghc from the distro, but I wanted to see what would happen with the "we'll download GHC for you" feature.

AfC

[snoyberg]

Have a look at #257 which has a similar issue for Arch. The solution we decided on there was documentation and testing: after installing a new GHC, we run a sanity check, and if it fails, point users to the Downloads page, which should (hopefully) have an explanation of how to fix these problems. You have any thoughts on that approach?

[istathar]

@snoyberg the solution that Halycon employed of (re)building and packaging the GHC binaries for various platforms seems worthwhile to think about here; we're already fetching the .tar from haskell.org; would be better to actually get it from (say) S3 or Fastly or whatever CDN as you are now doing for many of the other pieces that Stack is downloading, and if you're going to drive that and countenance rebuilding, it wouldn't be the end of the world to have binary built for each major platform family.

There are a lot of assumptions in that, but getting the compiler Just Working™ out of the box is a big deal and has long been a show stopper for adoption. @mietek did well here.

AfC

[snoyberg]

That's cool, I didn't realize that Halcyon had such a variety of Bindists for Linux.

@mietek Would you be opposed to us reusing the same bindists you're using for Halcyon?

[mietek]

@snoyberg: Halcyon is using official GHC bindists, as you can see here:
https://github.com/mietek/halcyon/blob/master/src/ghc.sh

However, that’s just the beginning. Further down the same file, you can see the code responsible for ensuring the right libraries are symlinked to the right locations for all of the platforms which Halcyon supports.

All in all, more than half of Halcyon code is responsible for making sure the right version of GHC and cabal-install is made available for the user’s project. Simply reusing Halcyon’s GHC and Cabal directory archives won’t help — you’ll basically need to reimplement Halcyon. But I thought you’re doing that anyway?

[gregwebs]

Well the good thing about stack is it doesn't need to worry about installing cabal-install!

Actually stack could just use Halcyon bash script on non-windows platforms to install GHC. It could then be gradually re-implemented to Haskell.

There would be some mis-match between the directory structure expected by Halcyon and then one that stack uses though. Just changing HALCYON_BASE may not be enough to integrate all the assumptions that the 2 projects make.

[mzero]

usually the problem with missing libgmp.so is that you need to install libgmp-dev or gmp-devel (depending on your distro).

[mietek]

…which sometimes contains a single symlink.

[snoyberg]

I don't have vast experience with lots of different distros, though I do have some. I've never found the "installing GHC" part to be difficult, the reason I wanted to automate it for stack was to make it easy to get the right version for the project being worked on, not because I thought installing GHC was a burden most users couldn't overcome (maybe I'm wrong here). In my experience, having a simple "on Fedora, run yum install ..." is sufficient to address this problem.

What I like about our installation process now is that it requires no root access, and is easily explainable in what it does: unpack GHC bindist, configure, and make install.

The idea of having a build tool go into /usr and start doing symlinking feels wrong to me. Is there a reason not to go with the approach that @mzero mentioned (installing -dev libraries or equivalent)?

[mietek]

Installing GHC only becomes a problem when your distro’s package manager doesn’t ship the version of GHC you’d like to install — or the version of libgmp needed for a particular version of GHC…

[snoyberg]

I've updated the Downloads page to include the necessary instructions for Fedora. I'm not a Fedora expert, but to my knowledge, the following is correct:

sudo yum install perl make automake gcc gmp-devel

perl is apparently needed by the GHC installation, go figure.

I believe the ideal that we're heading towards is having installers for stack itself for each distro, which includes the necessary system packages, and then allowing stack to install GHC as needed on demand.

@afcowie Would you be able to confirm that my instructions get things working on Fedora?

[istathar]

Are you building GHC, or just dumping a pre-built binary on people?

@snoyberg That list looks right. Can't say as I did anything particular to bring perl in but maybe it was a dependency of something else.

On thing you need to add: zlib-devel, in order to get /usr/lib64/libz.so. I'm always bummed out that I need to go get that manually. On other hand, I was surprised just now that you needed gmp-devel; this box I was testing on only has gmp installed. But I didn't build GHC...

AfC

Minor thing that makes this sort of documentation a nightmare: Fedora has adopted dnf as the package manager to replace yum. But that's not something you need to worry about; anyone using Fedora 22 will know that already, and anyone using RHEL 8 will find that out when RHEL 8 lands someday.

[radix]

(fwiw, I'm also not a fedora user/expert; just got curious and decided to poke around)

It seems the zlib package contains /usr/lib64/libz.so.1, but zlib-devel contains /usr/lib64/libz.so (perhaps as just a symlink? I can't tell) I'm using https://apps.fedoraproject.org/packages/zlib-devel/contents/ (which takes a very long time to load) to look at the package info. I'm used to the debian world where libfoo packages contain all the .so files and libfoo-dev packages contain headers, which are only necessary if the end user wants to compile their own software.

It looks like gmp and gmp-devel are laid out in the same way: the base package contains the versioned .so files and the -devel package contains the unversioned one.

[istathar]

@radix yeah, you're right; the -devel package is just libz.so symlink. That's annoying, but the Haskell zlib bindings in the zlib package link against -lz and so it needs to be there somewhere (most Haskell programs I've built need zlib sooner or later somewhere in the chain, so you hit it at some point).

[snoyberg]

Just unpacking the bindist from haskell.org.

It looks like this issue is resolved, closing.