Need ghc & stack binaries that work with older CentOS/RHEL

[dysinger]

See #461

[vamega]

I'd love to have this work, is there anything I can do to assist with this?

[borsboom]

I'm just now running into this in the process of making RPMs for Centos 6.x. Could stack look at the installed version of libgmp when deciding which GHC bindist to install (a centos-6.5/libgmp 4.x compatible bindist is provided at https://www.haskell.org/ghc/download_ghc_7_8_4#x86_64linux).

[borsboom]

Aside: would it make sense to provide separate stack binaries on the Github releases page for older libc/libgmp as well? I could integrate building both into the release tool using Docker. We could potentially "hard-code" the GHC bindist to use based on where stack was built (say, using a Cabal flag).

[snoyberg]

Yes we can do that with a bit of hackery in Stack.Setup. It makes the story
for cross compiling in the future a little bit more difficult, but this
should be a good solution for now. Want to take a stab at this?

On Thu, Jul 2, 2015, 5:09 PM Emanuel Borsboom notifications@github.com
wrote:

I'm just now running into this in the process of making RPMs for Centos
6.x. Could stack look at the installed version of libgmp when deciding
which GHC bindist to install (a centos-6.5/libgmp 4.x compatible bindist is
provided at https://www.haskell.org/ghc/download_ghc_7_8_4#x86_64linux).

—
Reply to this email directly or view it on GitHub
#465 (comment)
.

[borsboom]

I'm thinking about the best way to detect the libgmp version. Would it make sense for stack to run ldd on itself and use that to make the determination?

[borsboom]

I've committed support for stack setup installing the libgmp.so.3-compatible GHC "centos65" bindist on systems that only have libgmp.so.3. However, this has a serious limitation: it only works with GHC 7.8, since the GHC team does not provide a "centos65" bindist for GHC 7.10.

If the community provides a libgmp.so.3-compatible GHC 7.10 bindist, it's only a matter of making a PR on https://github.com/fpco/stackage-content/blob/master/stack/stack-setup.yaml to tell stack where to find that bindist.

[adinapoli]

I can confirm that now on my CentOS 6 box stack setup works as expected:

/tmp/pan/builds/pan-0.1.0.0 ⌚ 8:38:28
$ stack setup
Downloaded lts-2.16 build plan.
Caching build plan
Downloading package index from http://private-hackage/00-index.tar.gz
Populated index cache.
Downloaded ghc-7.8.4.
Installed GHC.
Would add the following to PATH: /home/alfredo/.stack/programs/x86_64-linux/ghc-7.8.4/bin

[borsboom]

Great! For now, I'm leaning toward not providing stack binaries for CentOS 6, since there doesn't seam to be much point on an OS that doesn't have binaries for the current GHC version. If you can build GHC from source, building stack from source isn't going to be a challenge.

[adinapoli]

I think it's your call - It's not difficult to just do a git clone commercialhaskell/stack && cd stack && cabal install and have a working stack installation, although it requires me to have the GHC toolchain installed in the first place, together with cabal-install.

Having CentOS 6 binaries for stack instead means that, if I stick to system-ghc: false I can blissfully use stack with no GHC installed on my system (rather than the prebuilt one stack will fetch for me with stack setup 😉

[borsboom]

Ok, this isn't really "official", but I had actually put together a CentOS 6 package repository before I realized GHC 7.10 wouldn't work, and I'm still updating it with new versions:

$ curl -sSL https://s3.amazonaws.com/download.fpcomplete.com/centos/6/fpco.repo | sudo tee /etc/yum.repos.d/fpco.repo
$ sudo yum -y install stack

I hesitated publicizing on the main downloads page because of the likely confusion if people try it and then find they can't actually do anything because GHC 7.10 isn't supported (this will become more of an issue when LTS 3 is released, which is happening soon).

No guarantees that this will keep getting updated, but for now it's part of the automated release tool so should be getting new releases for a while at least.

[adinapoli]

I indeed looked at it this morning (thanks for the effort!) but I was getting some trouble to get started :(

#523

[borsboom]

Looks like the GHC team has decided to provide gmp4 (libgmp.so.3)-compatible binaries for GHC 7.10.2, and I'm updating stack-setup.yaml (commercialhaskell/stackage-content@a163f0a) to include them in commercialhaskell/stackage-content#4. That means I'm going to plan on releasing stack binaries that support gmp4 as well.

[chadbrewbaker]

Yeah this is still a problem on AWS-Linux.

I'm not too keen on building my own libgmp anytime I want to fire off a vanilla AWS-Linux AMI but I guess that works, http://steve.planetbarr.com/blog/2014/02/26/setting-up-amazon-linux-ec2-with-ghc-7-dot-8-1-rc1-and-llvm/

stack: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory

[borsboom]

@chadbrewbaker Which binary are you using? We have binaries available that work on CentOS 6.x (RPM packages and plain gzipped binaries), which use libgmp4 (libgmp.so.3). If it's trying to use libgmp5 (libgmp.so.10), you are probably using the binaries meant for for newer OSs.

[chadbrewbaker]

Error message above was pulling from the CentOS7, downgrading to the CentOS6 as suggested above seemed to work on the current AWS-Linux.