ncurses woes

[Magnus Therning]

In the past I've had issues with haskeline complaining about
libtinfo.so. On my distro-of-choice (ArchLinux) no package actually
contains the links

/lib/libtinfo.so -> /lib/libtinfo.so.5
/usr/lib/libtinfo.so -> /usr/lib/libtinfo.so.5

so I had to create them myself. No big deal, just a bit irritating.
Creating them solved that problem.

Today I ran into another problem related to curses:

$ stach ghci
...
GHCi, version 8.0.2: http://www.haskell.org/ghc/ :? for help
<command line>: can't load .so/.DLL for: /usr/lib/gcc/x86_64-pc-linux-gnu/6.3.1/../../../../lib/libncurses.so (-lncursesw: cannot open shared object file: No such file or directory)

/lib/libncurses.so is apparently a linker script:

INPUT(-lncursesw)

and AFAIU that means it should go looking for `libncursesw.a` (which I
find a little strange). Anyway, I manually moved the linker script out
of the way and created the link

/lib/libncurses.so -> /lib/libncursesw.so.6

and now `stack ghci` works again. I don't like it though, because the
next update of ncurses will overwrite my changes and I have to remember
to re-apply them :(

- Can someone on this list confirm that my understanding of how
"INPUT(-lfoo)" works is correct?

- I'm unsure why a distro would use a linker script for something as
simple as that; a symbolic link seems to be equivalent, right?

- The reliance on each distro providing a proper ncurses package seems
to result in stack being a bit more brittle than I really like. Is
there any way to fix this?

/M

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

I would rather use Java than Perl. And I'd rather be eaten by a
crocodile than use Java.
— Trouser

[Emanuel Borsboom]

Stack itself doesn't use ncurses, it's GHC where these dependencies lie.  The issues with GHC's system dependencies and different versions of libgmp, libncurses/tinfo, and gcc on the system are a constant thorn in our side (albeit one we accept because having Stack manage multiple versions of GHC is so very useful).  I'd love it if we could bundle a statically linked GHC along with LLVM and whatever other tools are needed that would work across all Linux distros, but getting there will not be easy (if it's even possible).  Some people are even having trouble with the statically linked `stack` binaries we've been releasing in the last couple of versions, and Stack is a very simple program compared to GHC and its toolchain.

BTW, have you seen the ncurses5-compat-libs package in AUR?  It may help.  https://aur.archlinux.org/packages/ncurses5-compat-libs/

--
You received this message because you are subscribed to the Google Groups "haskell-stack" group.
To unsubscribe from this group and stop receiving emails from it, send an email to haskell-stac...@googlegroups.com.
To post to this group, send email to haskel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/haskell-stack/87lgrde2q2.fsf%40therning.org.
For more options, visit https://groups.google.com/d/optout.

[Magnus Therning]

Emanuel Borsboom <ma...@fpcomplete.com> writes:

> Stack itself doesn't use ncurses, it's GHC where these dependencies
> lie. The issues with GHC's system dependencies and different versions
> of libgmp, libncurses/tinfo, and gcc on the system are a constant
> thorn in our side (albeit one we accept because having Stack manage
> multiple versions of GHC is so very useful). I'd love it if we could
> bundle a statically linked GHC along with LLVM and whatever other
> tools are needed that would work across all Linux distros, but getting
> there will not be easy (if it's even possible). Some people are even
> having trouble with the statically linked `stack` binaries we've been
> releasing in the last couple of versions, and Stack is a very simple
> program compared to GHC and its toolchain.

Indeed, using stack to handle GHC is very useful! I'm just thinking that
if the various versions of GHC that are offered through stack are "built
for stack", then maybe it'd be possible to bundle in some shared libs
and do something clever with rpath and/or LD_LIBRARY_PATH.

I can report that even when using the Arch package for GHC together with
the Arch package for stack the same thing happens!
https://bugs.archlinux.org/task/53598

> BTW, have you seen the ncurses5-compat-libs package in AUR? It may
> help. https://aur.archlinux.org/packages/ncurses5-compat-libs/

Yes, I have that package installed already. Unfortunately it doesn't
help in this case (it doesn't even help fully with the libtinfo.so case
any more).

/M

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

Some people, when confronted with a problem, think,
“I know, I’ll use Regular Expressions.” Now they have two problems.
-- Jamie Zawinski

[Emanuel Borsboom]

Indeed, using stack to handle GHC is very useful! I'm just thinking that
if the various versions of GHC that are offered through stack are "built
for stack", then maybe it'd be possible to bundle in some shared libs
and do something clever with rpath and/or LD_LIBRARY_PATH.

That would be very interesting to try.  I would encourage anyone who wants to take that on!

 

[Magnus Therning]

Emanuel Borsboom <ma...@fpcomplete.com> writes:

> Stack itself doesn't use ncurses, it's GHC where these dependencies
> lie. The issues with GHC's system dependencies and different versions
> of libgmp, libncurses/tinfo, and gcc on the system are a constant
> thorn in our side (albeit one we accept because having Stack manage
> multiple versions of GHC is so very useful). I'd love it if we could
> bundle a statically linked GHC along with LLVM and whatever other
> tools are needed that would work across all Linux distros, but getting
> there will not be easy (if it's even possible). Some people are even
> having trouble with the statically linked `stack` binaries we've been
> releasing in the last couple of versions, and Stack is a very simple
> program compared to GHC and its toolchain.

A recent upgrade of the distro package removed my manual fix for this on
my systems, and got me thinking about it again.

What I don't understand here is *what* exactly is linking in
`libncurses.so`. I think I've managed to look through every single
binary, executable and .so, in
`~/.stack/programs/x86_64-linux/ghc-8.0.2/lib/ghc-8.0.2` and I don't
find *anything* actually linking to `libncurses.so`! (I ran `ldd` and
greped for 'curse', nothing.) I even ran the same search but using
`strings`, the only thing I found was 2 files in `package.conf.d/`.

Also, running `stack ghci` in $HOME doesn't trigger any linking error.
Manually loading a Haskell source file doesn't either. The only way I've
managed to trigger it is when running `stack ghci` in some stack-ified
projects (not in all!).

This is all rather puzzling to me! So, exactly what is pulling it in,
why only sometimes, and most importantly, how?

Any pointers on where I should look to understand this behaviour?

/M

--
Magnus Therning OpenPGP: 0x927912051716CE39
email: mag...@therning.org jabber: mag...@therning.org
twitter: magthe http://therning.org/magnus

Some people, wanting an escape from their full-time job, think
“I know, I'll contribute to open source.” Now they have two full-time
jobs.