FindCurses.cmake does not detect -ltinfo without CURSES_NEED_NCURSES
When building uhd (https://github.com/EttusResearch/uhd) on Gentoo a potential bug was uncovered in FindCurses.cmake
By default when upstream builds, it calls find_package(Curses) https://github.com/EttusResearch/uhd/blob/master/host/utils/latency/CMakeLists.txt#L8
This results in the following output during cmake:
-- Loading build info.
-- Found Curses: /usr/lib64/libcurses.so
Then the following build failure:
[419/702] : && /usr/bin/x86_64-pc-linux-gnu-g++ -Os -march=native -mtune=native -pipe -frecord-gcc-switches -fvisibility=hidden -fvisibility-inlines-hidden -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 examples/CMakeFiles/rx_ascii_art_dft.dir/rx_ascii_art_dft.cpp.o -o examples/rx_ascii_art_dft -Wl,-rpath,/var/tmp/portage/net-wireless/uhd-4.1.0.4/work/uhd-4.1.0.4/host_build/lib: lib/libuhd.so.4.1.0 -lcurses /usr/lib64/libform.so /usr/lib64/libboost_chrono.so.1.77.0 /usr/lib64/libboost_date_time.so.1.77.0 /usr/lib64/libboost_filesystem.so.1.77.0 /usr/lib64/libboost_program_options.so.1.77.0 /usr/lib64/libboost_serialization.so.1.77.0 /usr/lib64/libboost_thread.so.1.77.0 /usr/lib64/libboost_unit_test_framework.so.1.77.0 /usr/lib64/libboost_system.so.1.77.0 /usr/lib64/libboost_atomic.so.1.77.0 -lpthread -lpthread -ldl -lusb-1.0 lib/rc/libuhd-resources.a /usr/lib64/libpython3.9.so && :
[31mFAILED: [0mexamples/rx_ascii_art_dft
: && /usr/bin/x86_64-pc-linux-gnu-g++ -Os -march=native -mtune=native -pipe -frecord-gcc-switches -fvisibility=hidden -fvisibility-inlines-hidden -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 examples/CMakeFiles/rx_ascii_art_dft.dir/rx_ascii_art_dft.cpp.o -o examples/rx_ascii_art_dft -Wl,-rpath,/var/tmp/portage/net-wireless/uhd-4.1.0.4/work/uhd-4.1.0.4/host_build/lib: lib/libuhd.so.4.1.0 -lcurses /usr/lib64/libform.so /usr/lib64/libboost_chrono.so.1.77.0 /usr/lib64/libboost_date_time.so.1.77.0 /usr/lib64/libboost_filesystem.so.1.77.0 /usr/lib64/libboost_program_options.so.1.77.0 /usr/lib64/libboost_serialization.so.1.77.0 /usr/lib64/libboost_thread.so.1.77.0 /usr/lib64/libboost_unit_test_framework.so.1.77.0 /usr/lib64/libboost_system.so.1.77.0 /usr/lib64/libboost_atomic.so.1.77.0 -lpthread -lpthread -ldl -lusb-1.0 lib/rc/libuhd-resources.a /usr/lib64/libpython3.9.so && :
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: examples/CMakeFiles/rx_ascii_art_dft.dir/rx_ascii_art_dft.cpp.o: undefined reference to symbol 'LINES'
/usr/lib/gcc/x86_64-pc-linux-gnu/11.2.0/../../../../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
However, if I pass -DCURSES_NEED_NCURSES=TRUE to cmake the output changes to
-- Loading build info.
-- Looking for wsyncup in /usr/lib64/libcurses.so
-- Looking for wsyncup in /usr/lib64/libcurses.so - found
-- Looking for cbreak in /usr/lib64/libncurses.so
-- Looking for cbreak in /usr/lib64/libncurses.so - not found
-- Looking for nodelay in /usr/lib64/libncurses.so
-- Looking for nodelay in /usr/lib64/libncurses.so - not found
-- Found Curses: /usr/lib64/libncurses.so
And more importantly, build succeeds. I am not very good at reading cmake, but it seems that FindCurses.cmake correctly finds split tinfo only when CURSES_NEED_NCURSES set, but it should probably be checking unconditionally.