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

Closed
cdepillabout opened this Issue Jun 10, 2015 · 41 comments

Comments

@cdepillabout
Member

cdepillabout commented Jun 10, 2015

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:

$ stack setup --verbosity debug
2015-06-10 11:39:39.114682: [debug] Checking for project config at: /home/illabout/temp/picologic/stack.yaml @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Config src/Stack/Config.hs:451:9)
2015-06-10 11:39:39.115056: [debug] Loading project config file stack.yaml @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Config src/Stack/Config.hs:472:13)
2015-06-10 11:39:40.530401: [info] Downloading ghc-7.8.4 ... @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:576:5)
2015-06-10 11:39:40.530561: [debug] Downloading from https://www.haskell.org/ghc/dist/7.8.4/ghc-7.8.4-x86_64-unknown-linux-deb7.tar.xz to /home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4.tar.xz ... @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:581:5)
2015-06-10 11:39:40.530737: [debug] Already downloaded. @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:591:14)
2015-06-10 11:39:40.5314: [info] Unpacking GHC ... @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:476:9)
2015-06-10 11:39:40.531585: [debug] Unpacking /home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4.tar.xz @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:477:9)
2015-06-10 11:39:52.906265: [info] Configuring GHC ... @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:480:9)
2015-06-10 11:39:58.059003: [info] Installing GHC ... @(stack_45mxiajB96m5bnhfD5VS3t:Stack.Setup src/Stack/Setup.hs:484:9)
2015-06-10 11:40:39.483999: [error] Exit code ExitFailure 2 while running ["make","install"] in /tmp/stack-setup2750/ghc-7.8.4/ @(stack_45mxiajB96m5bnhfD5VS3t:System.Process.Read src/System/Process/Read.hs:169:13)

Running make install in the ghc directory manually gives me the following error:

...
Installing library in
/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/ghc-7.8.4
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/old-time dist-install "strip" '' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/old-time-1.1.0.2
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell98 dist-install "strip" '' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/haskell98-2.0.0.3
"utils/ghc-cabal/dist-install/build/tmp/ghc-cabal-bindist" copy libraries/haskell2010 dist-install "strip" '' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4' '/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/share/doc/ghc/html/libraries' 'v p dyn'
Installing library in
/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/haskell2010-1.1.2.0
"/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/bin/ghc-pkg" --force --global-package-db "/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/package.conf.d" update rts/dist/package.conf.install
/home/illabout/.stack/programs/x86_64-linux/ghc-7.8.4/lib/ghc-7.8.4/bin/ghc-pkg: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
ghc.mk:901: recipe for target 'install_packages' failed
make[1]: *** [install_packages] Error 127
Makefile:24: recipe for target 'install' failed
make: *** [install] Error 2

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, then stack setup succeeds.

It might be nice if stack setup could warn about this?

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 10, 2015

Here's my recommended course of action:

  1. Add information to the downloads page about necessary system libraries
  2. Add a sanity check to the end of stack setup to make sure it can compile a basic program
  3. If not, give an error message pointing to the downloads wiki page

What do you think?

@snoyberg snoyberg self-assigned this Jun 10, 2015

@snoyberg snoyberg added this to the First stable release (0.1.0.0?) milestone Jun 10, 2015

@cdepillabout

This comment has been minimized.

Member

cdepillabout commented Jun 10, 2015

That plan sounds really good.

I now see that the haskell-stack ackage already has a dependency on libtinfo.

https://aur4.archlinux.org/packages/haskell-stack/

snoyberg added a commit that referenced this issue Jun 10, 2015

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 10, 2015

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?

@drwebb

This comment has been minimized.

Contributor

drwebb commented Jun 10, 2015

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.

@cdepillabout

This comment has been minimized.

Member

cdepillabout commented Jun 10, 2015

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.

@snoyberg

This comment has been minimized.

Contributor

snoyberg commented Jun 11, 2015

Cool thanks!

On Thu, Jun 11, 2015, 12:13 AM Dennis Gosnell notifications@github.com
wrote:

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.


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

@urbanslug

This comment has been minimized.

urbanslug commented Sep 21, 2015

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.

$ ls /usr/lib | grep libtinfo         
libtinfo.so
libtinfo.so.6

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:

$  stack setup
The GHC located at /home/urbanslug/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc failed to compile a sanity check. Please see:

    https://github.com/commercialhaskell/stack/wiki/Downloads

for more information. Exception was:
Running /home/urbanslug/.stack/programs/x86_64-linux/ghc-7.10.2/bin/ghc /tmp/stack-sanity-check5745/Main.hs -no-user-package-db exited with ExitFailure 1
/home/urbanslug/.stack/programs/x86_64-linux/ghc-7.10.2/lib/ghc-7.10.2/package.conf.d/package.cache: openBinaryFile: does not exist (No such file or directory)

So I deleted my ~/.stack/ and reinstalled stack (and libtinfo using the PKGBUILD above). After a reboot stack setup was successful.

@drwebb

This comment has been minimized.

Contributor

drwebb commented Sep 22, 2015

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 extra, the Arch main repos won't have any issues building recent LTS snapshots, but projects dependent on old GHCs could fail.

At some point and there I two ways I see we could handle this. Either build a haskell-stack-ghc PKGBUILD and have all available compilers ready system wide and as a dependency of haskell-stackor we maintain a binary distribution of Arch Linux compatible GHC and have a stack setup managed download and unpacking.

Personally it sounds simpler to just upload the PKGBUILDs to build required GHCs from src and as a bin dist off ncurses GHC 7.10.2 frominstead of adding the logic to stack. I know a lot of people are running Arch, so any comments weighing in are welcome.

@drwebb drwebb reopened this Sep 22, 2015

@urbanslug

This comment has been minimized.

urbanslug commented Sep 22, 2015

What exactly do you mean by

build a haskell-stack-ghc PKGBUILD and have all available compilers ready system wide and as a dependency of haskell-stack

the part about system wide. I wish that everything be done on a per user basis as it currently is.

@snoyberg snoyberg modified the milestones: P2: Should, 0.1.0.0 Sep 23, 2015

@snoyberg snoyberg assigned drwebb and unassigned snoyberg Sep 23, 2015

@igrep

This comment has been minimized.

Contributor

igrep commented Sep 26, 2015

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.

@blippy

This comment has been minimized.

blippy commented Sep 26, 2015

Thanks igrep. I am a happy bunny now.

@drwebb

This comment has been minimized.

Contributor

drwebb commented Sep 26, 2015

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.

@ruuda

This comment has been minimized.

Contributor

ruuda commented Jun 13, 2016

It appears that this is still an issue.

$ pacman -Rns stack
$ pacman -S stack
You need to either 1) install latest stable ghc package from [extra] or 2) install libtinfo from AUR for the prebuilt binaries installed by stack to work.
Optional dependencies for stack
    ghc [installed]
$ ghc --version
The Glorious Glasgow Haskell Compilation System, version 8.0.1
$ stack setup
Preparing to install GHC to an isolated location.
This will not interfere with any system-level installation.
Already downloaded.                 
Running /usr/bin/make install in directory /tmp/stack-setup23779/ghc-7.10.3/ exited with ExitFailure 2
[...]
/home/ruud/.stack/programs/x86_64-linux/ghc-7.10.3/lib/ghc-7.10.3/bin/ghc-pkg: error while loading shared libraries: libtinfo.so.5: cannot open shared object file: No such file or directory
@borsboom

This comment has been minimized.

Contributor

borsboom commented Jun 13, 2016

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 libtinfo from the AUR to make the official bindists that stack setup uses work.

@borsboom borsboom reopened this Jun 24, 2016

@leohaskell

This comment has been minimized.

leohaskell commented Jun 25, 2016

@borsboom, on Arch, a temporary solution may be symlinking libtinfo to libncurses.

@ruuda

This comment has been minimized.

Contributor

ruuda commented Jun 25, 2016

It looks like terminfo already knows how to deal with this, but the dependency is hard-coded at configure/build time. If I understand correctly, if terminfo was built for a platform that has libtinfo instead of libcurses or libncurses, then it won’t work on a platform that has libcurses. (The Arch ncurses package provides both libcurses.so and libncurses.so.) Would it be possible to determine the dependency at runtime? See also this comment. If that is not possible, would a separate build for platforms that have libcurses instead of libtinfo solve the issue?

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jun 25, 2016

The ideal is that pacman -S stack and than stack setup "just works". So having to create a manual symlink first, or install an AUR package, is unfortunate. Stack could do a libtinfo vs. libncurses check at runtime and select a different GHC bindist (like it does with libgmp3 vs. libgmp5) but I'd really hope to be able to avoid needing to maintain more GHC bindists (there are currently two official ones, and we might start building a third soon).

@deinspanjer

This comment has been minimized.

deinspanjer commented Jun 26, 2016

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:

github repo

Docker hub build

@ChShersh

This comment has been minimized.

ChShersh commented Jun 28, 2016

Installing ncurses5-compat-libs also helps on Manjaro (16.06.1)

@GordonBGood

This comment has been minimized.

GordonBGood commented Jun 29, 2016

leohaskell

@borsboom, on Arch, a temporary solution may be symlinking libtinfo to libncurses.

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.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jun 29, 2016

@GordonBGood The easiest thing to do on Fedora 24 is install ncurses-compat-libs (which the Fedora 24 packages referenced in the installation instructions include as a dependency). See #2300.

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 stack setup also install the correct version of LLVM from a bindist alongside GHC.

@GordonBGood

This comment has been minimized.

GordonBGood commented Jun 30, 2016

@GordonBGood The easiest thing to do on Fedora 24 is install ncurses-compat-libs (which the Fedora 24 packages referenced in the installation instructions include as a dependency). See #2300.

@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.

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 stack setup also install the correct version of LLVM from a bindist alongside GHC.

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.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Jun 30, 2016

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.

@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.

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?

Yes, just like stack setup puts GHC is in a "private" location only used by Stack (and without interfering with any system-installed GHC), LLVM would also be isolated the same way. Further discussion should go in #2103.

jdnavarro added a commit to jdnavarro/smallcheck-series that referenced this issue Jul 3, 2016

Drop stack support
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.
@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 23, 2016

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?

@drwebb

This comment has been minimized.

Contributor

drwebb commented Aug 23, 2016

Using the Arch Linux Archive you can install an old package using pacman -U <path to .pkg.tar.xz> once you have downloaded the package locally. The
Arch Linux Archive for ghc is here
https://archive.archlinux.org/packages/g/ghc/

On Tue, Aug 23, 2016 at 9:21 AM, Emanuel Borsboom notifications@github.com
wrote:

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 kicking around?


You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
#257 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAK6UaQ-22Q56mtSHnlC1ZaoWmLfK0qdks5qix4LgaJpZM4E-XG2
.

Tristan Webb PhD
Haskell Application Engineer
FP Complete
San Diego, CA
M: 619-452-9545

@borsboom

This comment has been minimized.

Contributor

borsboom commented Aug 23, 2016

In e0b9b13 (to be included with stack-1.2.0), stack setup gains the ability to detect that it's running on a platform with libncurses6 and download an appropriate bindist. I've built 64-bit bindists for GHC 7.10.3 and 8.0.1 and tested them with stack setup on Arch. For older or 32-bit GHC versions, you'll still need to install libtinfo or ncurses5-compat-libs from.

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 borsboom closed this Aug 23, 2016

@theNerd247

This comment has been minimized.

theNerd247 commented Sep 10, 2016

@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 libtinfo.5.so error and this includes building 720f5f8 with my current setup.

@borsboom

This comment has been minimized.

Contributor

borsboom commented Sep 11, 2016

@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.

@spaghetti-

This comment has been minimized.

spaghetti- commented Oct 9, 2016

For gentoo users, reemerge sys-libs/ncurses with the tinfo use flag.

@fommil

This comment has been minimized.

fommil commented Jul 16, 2017

it's pretty crazy that stack is available in ArchLinux when its dependencies are not.

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