Summary: | sys-libs/ncurses-6.3_p20211106 and dev-util/cmake-3.22.3 provide incomplete find_package(Curses) implementation. | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Sergei Trofimovich <slyich> |
Component: | Current packages | Assignee: | Gentoo's Team for Core System packages <base-system> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | esigra, ionen, kde, mgorny, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://gitlab.kitware.com/cmake/cmake/-/issues/23236 https://bugs.gentoo.org/show_bug.cgi?id=837812 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 836696 | ||
Bug Blocks: |
Description
Sergei Trofimovich
2022-03-26 08:55:42 UTC
From the FindCurses.cmake documentation, I think applications needing to use tinfo symbols should be setting CURSES_NEED_NCURSES. I always treated -ltinfo as an internal implementation detail of ncurses. ncurses.pc seems to do the same. I personally don't expect software to know the fine distinction between -lcurses / -lncurses / -ltinfo / -ltermcap when it just needs "whatever libraries curses implementation provides on this platform". Proposed workaround upstream to assume ncurses for termcap interface as https://github.com/vikonix/multitextor/pull/22 (In reply to Sergei Trofimovich from comment #2) > I always treated -ltinfo as an internal implementation detail of ncurses. > ncurses.pc seems to do the same. I personally don't expect software to know > the fine distinction between -lcurses / -lncurses / -ltinfo / -ltermcap when > it just needs "whatever libraries curses implementation provides on this > platform". > > Proposed workaround upstream to assume ncurses for termcap interface as > https://github.com/vikonix/multitextor/pull/22 No disagreement there, but given how brittle Find*.cmake modules are in general, I don't see Kitware changing its position here (https://gitlab.kitware.com/cmake/cmake/-/issues/23236#note_1143848). Curious I've just hit a similar problem with LLDB. Reading FindCurses.cmake, the logic is really weird: it seems to assume ncurses unless libcurses.so is present. Perhaps the best solution would be to stop installing 'libcurses.so' symlink and expect software to use -lncurses. (In reply to Michał Górny from comment #4) > Curious I've just hit a similar problem with LLDB. Reading > FindCurses.cmake, the logic is really weird: it seems to assume ncurses > unless libcurses.so is present. > > Perhaps the best solution would be to stop installing 'libcurses.so' symlink > and expect software to use -lncurses. This is now done. |