-
Notifications
You must be signed in to change notification settings - Fork 842
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
ghc fails to install on Arch Linux because of missing libtinfo.so.5 #257
Comments
Here's my recommended course of action:
What do you think? |
That plan sounds really good. I now see that the |
OK, sanity check added. Could I ask you to add some content to the Downloads page about the missing library and how to fix it on Arch Linux? |
As you noticed, if you are on Arch you probably should be using the package in the AUR, which has this dependency already. Think this is ready to close. |
Okay, I added a note to the downloads page about Arch Linux. https://github.com/commercialhaskell/stack/wiki/Downloads#arch-linux The sanity check looks good. |
Cool thanks! On Thu, Jun 11, 2015, 12:13 AM Dennis Gosnell [email protected]
|
This issue has arisen yet again. The problem now is that stack is looking for libtinfo-5. However, on arch there is libncurses 6 which has been caused by an upgrade. So the libtinfo package from the AUR that @cdepillabout linked creates the symlink libtinfo.so.6 instead.
However this can be solved by installing libtinfo using the following archlinux PKGBUILD https://gist.github.com/jdnavarro/975158123f34b5c8f156 but when running stack setup I still got the failure:
So I deleted my ~/.stack/ and reinstalled stack (and libtinfo using the PKGBUILD above). After a reboot |
Installing libtinfo-5 isn't really a solution once ncurses gets bumped to version 6.x. ncurses going to 6.0 broke a lot of packages on my install, including my local stack setup. In the future we want to avoid this situation, 7.10.2 will be legacy at some point. I haven't tested, but older versions of GHC should also be broken. Once 7.10.2 goes into At some point and there I two ways I see we could handle this. Either build a Personally it sounds simpler to just upload the PKGBUILDs to build required GHCs from src and as a bin dist off |
What exactly do you mean by
the part about system wide. I wish that everything be done on a per user basis as it currently is. |
Seems we can avoid this problem by reinstalling both libtinfo and stack (along with GHCs installed by stack). $ yaourt -R haskell-stack
$ yaourt -R libtinfo
$ yaourt -S haskell-stack
$ stack setup Worked for at least when installing GHC 7.10.2. |
Thanks igrep. I am a happy bunny now. |
After upgrading to the new ncurses-6 and the libtinfo-6, I needed to also nuke ~/.stack. Everything has been working fine her as well. Closing. |
It appears that this is still an issue.
|
Yeah, the situation with Arch is tricky because the official GHC bindists don't work on it, exacerbated now by the fact that Arch's official GHC package is version 8.0.1, while stack uses 7.10.3 by default (because there's no Stackage LTS release for 8.0.1 yet). I believe you'll need to install |
It looks like |
The ideal is that |
I was sorta stumbling along trying to get a version of a Haskell app, Postgrest running in an Alpine Linux 3.4 Docker image. I hit this issue while working on that. If anyone wants to take a look or needs a test bed to play around and see the issue, please feel free to take a look: |
Installing |
leohaskell
That's what I did on Fedora 24: created a "libtinfo.so.5" symlink linking to "libtinfo.so.6" in the same folder as the latter, which is "/usr/lib64/". "libtinfo.so.6" was created/checked by my version of ncurses.config to point to the actual shared library, "libtinfo.so.6.0" in this case It works with haskel-platform/GHC version 8.0.1. I could have also symlink'ed to "libtinfo.so" in the same folder, which then would have a reasonable chance of working even if ncurses gets updated to higher versions. The trouble with GHC and its toolchain is there are too many dependencies on specific versions of external libraries, whether actual or forced as here. It seems that it could have just used "libtinfo.so" instead of the specific version "libtinfo.so.5" and everything would have been fine. A worse issue is that of GHC's use of the LLVM backend (which is supposed to be fixed by GHC 8.2.1): currently it depends on LLVM 3.7, where recent distro's are updated to LLVM 3.8. One has to download the old version from the LLVM download site (LLVM comes bundled with Clang), unpack it somewhere, and put that path ahead of the installed one as per: http://stackoverflow.com/a/18035789. Alternatively, one can just copy the two files "llc" or "opt" to /usr/bin. The problem with both of these solutions is that the newer versions aren't then accessible or are broken. Better is to use the GHC command line options "-pgmlc(cmd)" and "-pgmlo(cmd)" to designate where to find llc and opt (which might well be to copies of the version 3.7 ones in the /usr/local/Haskell/ghc-8.0.1-x86_64/bin folder), in which case no system changes need be made. It may well be that this is where GHC 8.2.1 will search for them by default, so no changes to compilation would need to be made when that version comes out. |
@GordonBGood The easiest thing to do on Fedora 24 is install Regarding LLVM, it's even worse because GHC 7.10.3 isn't compatible with even LLVM 3.7 (it needs 3.5). Over in #2103 we're discussing ARMv7 support which requires LLVM, and one of the options is having |
@borsboom, I had tried installing ncurses5-compat-libs as per @chshersh above, but of course there is no '5' version for fedora, I just tested your ncurses-compat-libs and it does work, replacing my symlink with its own.
GHC 7.10.3 is the same problem with the same solution as I suggested for LLVM except one needs the LLVM version 3.5 distribution versions of at least llc and opt. Does "installing the correct (older) version of LLVM from a bindist alongside GHC" allow other applications to use the new version of LLVM/Clang installed by the operating sytem if they require it? If so, I'm all for it. Even easier is just to put the required versions of the LLVM programs "llc" and "opt" in the exec folder of ghc, which for a normal HaskellPlatform Linux install is /usr/local/Haskell/ghc-8.0.1-x86_64/lib/ghc-8.0.1/bin. GHC will then find them there when it needs them for -fllvm builds and won't look elsewhere. That's what I currently do and it works. This way, I don't have to mess with -pgmlc and -pgmlo options to ghc in the calling script. Also, Clang and LLVM 3.8 work as usual for the operating system as expected. Of course, as I mentioned, GHC 8.2.1 is supposed to fix this, with options to install llc and opt alongside or within the GHC distribution without interfering with whatever version of LLVM is installed in the operating system. |
@GordonBGood: Arch Linux and Fedora 24 are completely separate Linux distributions that use totally different package systems, and this issue is for Arch Linux. For Fedora 24, #2300 is where you should look.
Yes, just like |
I'm doing this because of commercialhaskell/stack#257 My main Haskell development machine is Arch Linux and I previously went throught the workarounds to make `stack` work with Arch, but currently I don't have time to keep reconciling the libraries needed by `stack` with the ones provided by Arch.
Does anyone know how to install an older version of GHC on Arch (e.g. 7.8.4., although 7.10.* would be OK too)? Alternatively, does anyone have an old GHC bindist that works on Arch w/ ncurses6 kicking around? |
Using the Arch Linux Archive you can install an old package using On Tue, Aug 23, 2016 at 9:21 AM, Emanuel Borsboom [email protected]
Tristan Webb PhD |
In e0b9b13 (to be included with stack-1.2.0), I'd be happy to accept 32-bit and/or older GHC bindists from contributors. See GHC build instructions. Please re-open this issue if you run into any trouble with it. |
@borsboom Could you provide the binary package for the current build of rc/v1.2.0 ? I'm trying to build this checkout of stack on my system so that I can build stack based programs that require GHC 7.10.* . I'm running into this issue on my Arch machine with a fresh install of stack and ghc. So far using the nightly-2016-09-09 for new stackage projects avoids this issue, however when attempting to compile projects using older resolvers fails with the |
@theNerd247: I'll be releasing binaries once 1.2.0 is ready to release (it currently crashes on some architectures). In the meantime, you should be able to install ncurses5-compat-libs from AUR to get things working. |
For gentoo users, reemerge |
it's pretty crazy that |
When running
stack setup
on Arch Linux, ghc-7.8.4 fails to install because of a missing libtinfo.so.5 library.Here is the output of
stack setup
:Running
make install
in the ghc directory manually gives me the following error:It appears that on Arch Linux, programs should be linked against libncurses.so.5 instead of libtinfo.so.5:
https://aur.archlinux.org/packages/libtinfo/
If the above package
libtinfo
is installed from AUR, thenstack setup
succeeds.It might be nice if
stack setup
could warn about this?The text was updated successfully, but these errors were encountered: