Initially the problem was observed on the following small ebuild: $ cat multitextor-9999.ebuild EAPI=8 inherit cmake git-r3 DESCRIPTION="Multiplatform command line text editor." HOMEPAGE="https://github.com/vikonix/multitextor" EGIT_REPO_URI="https://github.com/vikonix/multitextor.git" LICENSE="BSD-2" SLOT="0" KEYWORDS="~amd64 ~x86" RDEPEND=" sys-libs/gpm:= sys-libs/ncurses:= " DEPEND="${RDEPEND}" # emerge -v1 multitextor ... /usr/bin/x86_64-pc-linux-gnu-g++ -O2 -pipe -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu -pthread Editor/CMakeFiles/multitextor.dir/src/Config.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/FileDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/FindDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/FindFileDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/GotoDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/PropertiesDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Dialogs/WindowListDialog.cpp.o Editor/CMakeFiles/multitextor.dir/src/Editor.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorApp.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorAppFunc.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorCmd.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorMenu.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorWnd.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorWndDialogs.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorWndEditFunc.cpp.o Editor/CMakeFiles/multitextor.dir/src/EditorWndMoveFunc.cpp.o Editor/CMakeFiles/multitextor.dir/src/LexParser.cpp.o Editor/CMakeFiles/multitextor.dir/src/UndoList.cpp.o Editor/CMakeFiles/multitextor.dir/src/main.cpp.o -o /dev/shm/portage/app-text/multitextor-9999/work/multitextor-9999/_build/bin/multitextor ThirdParty/libThirdPartyLib.a Utils/libUtilsLib.a Console/libConsoleLib.a WndManager/libWndManagerLib.a Console/libConsoleLib.a Utils/libUtilsLib.a ThirdParty/libThirdPartyLib.a -ldl -lcurses && : /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: Editor/CMakeFiles/multitextor.dir/src/Dialogs/FileDialog.cpp.o: in function `_WndManager::WndManager::WndManager()': FileDialog.cpp:(.text._ZN11_WndManager10WndManagerC2Ev[_ZN11_WndManager10WndManagerC5Ev]+0x3ec): undefined reference to `tgetent' multitextor is a cmake-based program. It discovers ncurses in a very conventional way: From Console/CMakeLists.txt: find_package(Curses REQUIRED) target_link_libraries(${PROJECT_NAME} PRIVATE ${CURSES_LIBRARY}) It should Just Work. The problem here is that on Gentoo `find_package(Curses)` returns `-lcurses` which is an incomplete linker script as it lacks tinfo: $ cat /usr/lib64/libcurses.so ... GROUP ( /lib64/libncurses.so.6 ) On Ubuntu and Fedora /usr/lib64/libcurses.so is a linker script that contains both libraries. I think eitheer Gentoo's `cmake` should return both `-lcurses -ltinfo` to make `find_package(Curses)` do the right thing or should have a similar hack for `libcurses.so`. Reproducible: Always Steps to Reproduce: The following self-contained example should illustrate the problem: $ cat CMakeLists.txt cmake_minimum_required(VERSION 3.22) project (bug) add_executable (bug bug.c) find_package(Curses REQUIRED) target_link_libraries (bug PRIVATE ${CURSES_LIBRARIES}) cat bug.c #include <ncursesw/ncurses.h> #include <term.h> int main(int argc, char * argv[]) { if (argc > 100) tgoto(0, 0, 0); } Using: # make VERBOSE=1 /usr/bin/cmake -S/root/example -B/root/example/b --check-build-system CMakeFiles/Makefile.cmake 0 /usr/bin/cmake -E cmake_progress_start /root/example/b/CMakeFiles /root/example/b//CMakeFiles/progress.marks make -f CMakeFiles/Makefile2 all make[1]: Entering directory '/root/example/b' make -f CMakeFiles/bug.dir/build.make CMakeFiles/bug.dir/depend make[2]: Entering directory '/root/example/b' cd /root/example/b && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /root/example /root/example /root/example/b /root/example/b /root/example/b/CMakeFiles/bug.dir/DependInfo.cmake --color= make[2]: Leaving directory '/root/example/b' make -f CMakeFiles/bug.dir/build.make CMakeFiles/bug.dir/build make[2]: Entering directory '/root/example/b' [ 50%] Building C object CMakeFiles/bug.dir/bug.c.o /usr/bin/cc -MD -MT CMakeFiles/bug.dir/bug.c.o -MF CMakeFiles/bug.dir/bug.c.o.d -o CMakeFiles/bug.dir/bug.c.o -c /root/example/bug.c [100%] Linking C executable bug /usr/bin/cmake -E cmake_link_script CMakeFiles/bug.dir/link.txt --verbose=1 /usr/bin/cc CMakeFiles/bug.dir/bug.c.o -o bug -lcurses /usr/lib64/libform.so /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: CMakeFiles/bug.dir/bug.c.o: undefined reference to symbol 'tgoto' /usr/lib/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libtinfo.so.6: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status make[2]: *** [CMakeFiles/bug.dir/build.make:99: bug] Error 1 make[2]: Leaving directory '/root/example/b' make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/bug.dir/all] Error 2 make[1]: Leaving directory '/root/example/b' make: *** [Makefile:91: all] Error 2 Actual Results: linking against tinfo fails. Expected Results: linking against tinfo should succeed.
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.
