Linker error with 'stack ghci'

[pharpend]

Source tree: https://github.com/pharpend/desbot

[src/desbot master] % stack ghci
Configuring GHCi with the following packages: desbot
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)
[src/desbot master] % locate libncurses.so
/usr/lib/libncurses.so
/usr/lib/libncurses.so.5
/usr/lib/libncurses.so.5.9

[snoyberg]

I was unable to reproduce this on Ubuntu 14.04.

[snoyberg]

FYI, on my system:

locate libncurses.so
/lib/x86_64-linux-gnu/libncurses.so.5
/lib/x86_64-linux-gnu/libncurses.so.5.9
/usr/lib/x86_64-linux-gnu/libncurses.so

Maybe you're missing the 64-bit version of the library?

[chrisdone]

-lncursesw: cannot open shared object file: No such file or directory

@pharpend There's a w in there (presumably for "wide"; unicode):

chris@retina:~$ locate libncursesw.so
/lib/x86_64-linux-gnu/libncursesw.so.5
/lib/x86_64-linux-gnu/libncursesw.so.5.9

[pharpend]

@snoyberg I'm on Arch Linux 64-bit.

@chrisdone My libraries are in different locations:

[~] % locate libncursesw.so
/usr/lib/libncursesw.so
/usr/lib/libncursesw.so.5
/usr/lib/libncursesw.so.5.9

I think the key here is to figure out which program is producing the linker error: is it GHC, GHCi, Stack, Cabal-the-library?

Whichever program it is, it seems to be using a non-standard method of locating shared object files.

[pharpend]

FWIW, I'm getting the same error with the version of stack in master. (Previously, I was using the Hackage version).

I got a new system update today, so I'll see if that fixes it.

Edit: No fix from system update.

[pharpend]

I should mention, I can use normal ghci and cabal repl without issue

[pharpend]

So, I actually bothered to trace through the ..s, and the shared object file does indeed exist at that location. I don't know where GHC is getting this idea that the file doesn't exist.

[pharpend]

Well, now I'm getting the same issue with cabal repl:

Preprocessing library desbot-0.1.0.0...
GHCi, version 7.10.1: http://www.haskell.org/ghc/  :? for help
<command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-unknown-linux-gnu/5.1.0/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)

[pharpend]

I'm thinking this might be a problem with GNU Readline, as it depends on ncurses.

[cocreature]

I run into the same problem with stack on arch 64bit. Compiling a c hello world with -lncursesw is working fine and the file mentioned in the error message exists.

[geekosaur]

This looks familiar. Debian oldstable (at least; haven't checked wheezy) makes libncurses.so a GNU linker script containing INPUT(-lncursesw). Something is assuming that the parameter to INPUT is a pathname and trying to open it directly, whereas ld would do a normal library search at that point. I presume Arch is doing something similar. The bug trackers for the various curses packages on Hackage should have plenty of examples.

(That said, I thought ghci used the system linker in 7.10?)

[Earnestly]

Yes, /usr/lib/libncurses.so is a linker script on Arch as well with the same
contents.

[pharpend]

@geekosaur Without filing a thousand other bug reports, is there a fix and/or a temporary workaround?

[geekosaur]

The usual workaround is to replace the linker script with a symlink. This may annoy the system package manager, but people on Debian have not reported issues with it, and have had this issue with hs-curses etc. for several years now (Debian stable being what it is) so I would expect that problems would have been noticed by now.

The upstream bug is with ghc / ghci, and is one of the things that was supposed to be fixed by using the system linker instead of a home-grown one in the bytecode backend. 7.10.1 seems to have some other linker issues as well (and it may be too late to get fixes into 7.10.2.

[pharpend]

@geekosaur That worked. Since this appears to be a bug with GHC, not Stack, I'm closing this issue.

[puffnfresh]

I had this problem on Nix. Turns out the ncurses package was split into two parts, out having just libs and dev having the headers:

nix:
  packages: [ncurses.out, ncurses.dev]

If you write ncurses you'll only get ncurses.dev.

It wasn't enough for me to make stack.yaml reference both in my project, because Stack caching. I had to clear out my ~/.stack directory. Below is why, if you care.

---

It looks like Stack only checks compilation before caching packages, it does not check runtime linking. If you compile terminfo with just ncurses in your packages, then you will get:

library-dirs: /home/brian/.stack/snapshots/x86_64-linux-nix/lts-5.13/7.10.3/lib/x86_64-linux-ghc-7.10.3/terminfo-0.4.0.2-GTEmnLYt1ob2hCwhW9sVjr
              /nix/store/6djmaps8h2a1n05wzmgf774gkk5x1dij-ghc-7.10.3/lib
              /nix/store/hh1y3nd88a0cbs78b060rzlhig9lj69y-ncurses-5.9-dev/lib

So only the headers and no libs will be in library-dirs. Adding ncurses.out into your packages doesn't invalidate the terminfo package and you'll have a built terminfo which can't be run in GHCi.

[mgsloan]

One option for more selectively re-building a package is stack exec -- ghc-pkg unregister X.