This has mostly caused issues in regards to Haskell for me personally, as mentioned in #7403 (although I've also had issues with building several Haskell packages, including Haskeline), but I can only imagine there are issues elsewhere as well.
While it's possible to modify software packaged for Void to use libncurses rather than libtinfo, I assume, when used for a developer system it's often impossible or infeasible to modify all of the software and libraries you're using to conform to Void Linux's choices.
As mentioned in this comment, most distributions have standardized on providing libtinfo along with libncurses, and I'm of the opinion that Void Linux should follow suit.
@Hoshpak I would consider this more bug-adjacent than enhancement to be honest, since it's actively causing a problem for me and other users, using anything with binary distributions that link to libtinfo or libraries that use tinfo.h at compile time. I can turn it into a proper bug report if required, but I was mostly creating this to show that the issue demonstrated in #7403 has more overarching effects
I can definitely generate a "minimum example haskell project" that will reproducibly cause you to run into this issue if that's desired, but that's the kind of thing you demonstrate in a bug report to upstream, not in a bug report on a distro for going against the existing packaging conventions of other distros which I'm of the opinion is the problem that needs addressing, rather than the upstream of every single piece of software ever to link to an expected library.
My reasoning was: You want a feature to be added that the package currently does not have so it's an enhancement.
It's not one of Void's goals to support binary distributions compiled by other people so that's hardly relevant. (And there are better mechanisms for providing distribution-independent binaries than relying on distributions to build things in a certain way) Conventions of other distributions can be used as a guideline where appropriate but not more so doing things differently is not a bug imho.
That being said, what label is attached to an issue does not change it's priority or the likelyhood that it will be dealt with. Github issues are being dealt with on a volunteer basis so someone who is interested in solving this needs to step up and do it.
I am also not saying that this shouldn't be changed. A PR that changes the template without causing regressions will most likely be accepted.
Am 14. Mai 2019 18:49:30 MESZ schrieb Ashlynn Anderson notifications@github.com:
@Hoshpak I would consider this more bug-adjacent than enhancement to be
honest, since it's actively causing a problem for me and other users,
using anything with binary distributions that link to libtinfo or
libraries that use tinfo.h at compile time. I can turn it into a proper
bug report if required, but I was mostly creating this to show that the
issue demonstrated in #7403 has more overarching effectsI can definitely generate a "minimum example haskell project" that will
reproducibly cause you to run into this issue if that's desired, but
that's the kind of thing you demonstrate in a bug report to upstream,
not in a bug report on a distro for going against the existing
packaging conventions of other distros which I'm of the opinion is the
problem that needs addressing, rather than the upstream of every single
piece of software ever to link to an expected library.--
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/void-linux/void-packages/issues/11718#issuecomment-492318521
The configure script of ncurses supports --with-termlib which makes our template create two additional (for widec and regular) SOLIBS /usr/lib/libtinfow.so.6.1 and /usr/lib/libtinfo.so.6.1 and their usual symlinks.
I can try to update the template to build tinfo and the compatibility symlinks if noone has concerns.
Actually this change causes trouble in dependencies e.g. libreadline8 -> lvm2. Now lvm2 cannot find the library containing tgetent. I'll have to revert that change and revbump ncurses to fix that :-(
I have to leave solving this enhancement request for someone who can also solve the consequences of adding tinfo to ncurses, sorry.
How do you tell ncurses to build libtinfo? I'm trying to do so for the reasons stated above (Haskeline fails to build without it), but adding "--with-termlib" to the configure_args string returns build errors.
Here are the last of the listed errors:
=> ncurses-devel-6.1_5: running pre-pkg hook: 90-set-timestamps ...
=> ncurses-devel-6.1_5: setting mtimes to Tue 03 Dec 2019 09:28:30 AM PST
=> ncurses-devel-6.1_5: running pre-pkg hook: 99-pkglint-subpkgs ...
=> ncurses-devel-6.1_5: running pre-pkg hook: 99-pkglint ...
=> ncurses-libs-6.1_5: running pre-pkg hook: 03-rewrite-python-shebang ...
=> ncurses-libs-6.1_5: running pre-pkg hook: 04-generate-runtime-deps ...
SONAME: libtinfo.so.6 <-> UNKNOWN PKG PLEASE FIX!
SONAME: libc.so.6 <-> glibc>=2.29_1
SONAME: libtinfow.so.6 <-> ncurses-libs (ignored)
SONAME: libncursesw.so.6 <-> ncurses-libs-5.8_1 (ignored)
=> ERROR: ncurses-libs-6.1_5: cannot guess required shlibs, aborting!
i would also be interested in how to properly address the libtinfo.so issue. On my system i've made /lib/libtinfo.so a symlink to /usr/lib/libcurses.so, but i'm not sure that's the best way of handling it?
I added this to void-packages/common/shlibs:
libtinfow.so.6 ncurses-libs-6.1_5 ignore
libtinfow.so.5 ncurses-libs-6.1_5 ignore
libtinfo.so.6 ncurses-libs-6.1_5 ignore
libtinfo.so.5 ncurses-libs-6.1_5 ignore
After successfully running ./xbps-src -f pkg ncurses with this change, xi -f ncurses failed with the following:
[*] Updating `https://mirror.clarkson.edu/voidlinux/current/x86_64-repodata' ...
ncurses-6.1_5: broken, unresolvable shlib `libtinfow.so.6'
Transaction aborted due to unresolved shlibs.
I strongly recommend if you're needing to build haskeline for a Haskell package or application you're writing, you just go ahead and install nix and use the stack (and cabal has something similar as well) nix integration and explicitly declare required packages in stack.yaml under the nix section.
This doesn't require writing any actual nix code, so it's a pretty easy way to do things.
It also incidentally works as a workaround for now on void linux although I'd recommend it in any case
I'm encountering errors building rust applications that rely on ncurses because of this.
Any update?
I wanted to build: https://github.com/dankamongmen/notcurses
But it failed because can't find __tinfo__.
I am trying to update arduino to 1.8.11 and I have the build fails to compile because it can't find tinfo.