Skip to content
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
Closed

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

dysinger opened this issue Jun 30, 2015 · 15 comments
Assignees
Milestone

Comments

@dysinger
Copy link
Contributor

@dysinger dysinger commented Jun 30, 2015

See #461

@vamega
Copy link

@vamega 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@snoyberg 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
Copy link
Contributor

@borsboom 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
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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@adinapoli 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@adinapoli 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@adinapoli 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@chadbrewbaker 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
Copy link
Contributor

@borsboom 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
Copy link
Contributor

@chadbrewbaker 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
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants