New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
dysinger opened this Issue Jun 30, 2015 · 15 comments

Comments

Projects
None yet
6 participants
@dysinger
Contributor

dysinger commented Jun 30, 2015

See #461

@vamega

This comment has been minimized.

vamega commented Jul 2, 2015

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

@snoyberg snoyberg added this to the 0.2.0.0 milestone Jul 2, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 3, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 3, 2015

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

This comment has been minimized.

Contributor

snoyberg commented Jul 3, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 3, 2015

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 added a commit that referenced this issue Jul 3, 2015

'stack setup' can install libgmp.so.3 GHC (#465)
If only libgmp.so.3 is available, uses the '-centos65' bindist.
Otherwise, the '-debian7' bindist is used.

This only currently works with GHC 7.8, since the GHC team does not
provide libgmp.so.3-compatible bindists for GHC 7.10.
@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 3, 2015

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

This comment has been minimized.

Contributor

adinapoli commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

This comment has been minimized.

Contributor

adinapoli commented Jul 6, 2015

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

This comment has been minimized.

Contributor

borsboom commented Jul 6, 2015

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

This comment has been minimized.

Contributor

adinapoli commented Jul 6, 2015

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

#523

@borsboom borsboom closed this Jul 10, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jul 30, 2015

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

This comment has been minimized.

Contributor

chadbrewbaker commented Aug 9, 2015

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

This comment has been minimized.

Contributor

borsboom commented Aug 9, 2015

@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

This comment has been minimized.

Contributor

chadbrewbaker commented Aug 10, 2015

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment