configure fails on curses checks missing stdscr

[seidler]

The configure script on the main branch fails while it checks for curses libraries.
It creates a conftest.c program which refers to a curses stdscr variable with
extern void* stdscr;
I suppose the proper way of using stdscr would be to use the initscr function. For a configuration test declaring the variable should be fair enough by removing the extern keyword:
void* stdscr;
This shall be done in configure.ac

I am refering to commit 9c316cc

[seidler]

For me the following patch worked:

diff --git a/configure.ac b/configure.ac
index 40a83063..54f6e0e2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -458,7 +458,7 @@ htop_check_curses_capability () {
    AC_LINK_IFELSE([AC_LANG_PROGRAM([[
 /* extern WINDOW* stdscr; */
 /* int keypad(WINDOW* win, bool enable); */
-void* stdscr;
+extern void* stdscr;
 int keypad(void* win, int enable);
       ]], [[
 keypad(stdscr, 0);

[BenBE]

Please provide the full configure.log and the necessary information about your system.

Declaring extern void* stdscr; is intetional in the test, as configure tries to find if the curses library provides a symbol called stdscr.

[seidler]

The system is an Opensuse Leap Version 15.5 on an amd_64 processor.

The config.log.gz file is attached.

config.log.gz

[Explorer09]

From the attached config.log.gz

retrieving ncursesw information through /usr/bin/pkg-config
configure:7976: result: found ncursesw information through /usr/bin/pkg-config
curses cflags: -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw
curses libs: -lncursesw -ltinfo
configure:7837: checking for keypad in -lncursesw -ltinfo
configure:7857: gcc -o conftest -std=c99 -pedantic -D_GNU_SOURCE -D_DEFAULT_SOURCE -I/usr/include/ncursesw -g -O2   conftest.c -lncursesw -ltinfo -ldl -lm  >&5
/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/ld: /tmp/ccuG8vgs.o: in function `main':
/home/uwe/dl/acerdl/htop/htop/conftest.c:64:(.text.startup+0x7): undefined reference to `stdscr'
collect2: error: ld returned 1 exit status
configure:7857: $? = 1

The libraries -lncursesw -ltinfo seem to both exist, but for some reasons -ltinfo misses the necessary stdscr symbol.

What would happen if you try to find the stdscr symbol using nm command on libtinfo.so.6? Not sure if this could help find out the problem.

[BenBE]

What's the output for

nm -D /lib/x86_64-linux-gnu/libncurses*.so*

and

nm -D /lib/x86_64-linux-gnu/libtinfo*.so*

Adapt the paths as necessary for where the dynamic libraries are found on your system …

[seidler]

The command
nm -D /lib64/libtinfo.so.6.1 > nm-D_libtinfo.so.6.1.txt
creates
nm-D_libtinfo.so.6.1.txt

therein I find
000000000000cf20 T _nc_stdscr
code in text segment

[BenBE]

What does this command return?

ls -la /lib64/libncurses*.so* /lib64/libtinfo*.so*

Especially the symlinks are of interest.

What does the compiler tell about its libdir?

gcc -v
gcc -print-search-dirs

Can you try to reproduce the failed conftest standalone and include an additional -v in the command line?

[Explorer09]

therein I find 000000000000cf20 T _nc_stdscr code in text segment

My expectation is xxxxxxxxxxxxxxxx B stdscr without any rename.

From the <curses.h> header in ncurses source code, the redirect can happen if ncurses is built with NCURSES_REENTRANT. htop's configure missing that check is surely a bug.

@seidler Can your htop build and run properly if you skip that stdscr check with your hack? If it can run properly, then I can try changing the stdscr check to make it less harsh.

[Explorer09]

@BenBE This case is interesting as htop's configure had neven been checking for libncursestw or libtinfotw (note the letter 't'), but OpenSUSE seems to provide libncursestw as libncursesw. So, if I were to fix this, it would be adding libncursestw into the configure check, while also address the stdscr thing.

But did anyone ever succeed building and running htop with libncursestw? It's the first question I wish to get answer.

[seidler]

If I patch the configure.ac as described, htop can be build and it works fine (for me) as does usually.

[seidler]

@BenBE :
Hopefully I did not forget anything:

ls -la /lib64/libncurses*.so* /lib64/libtinfo*.so*
lrwxrwxrwx 1 root root     17 10. Sep 14:54 /lib64/libncurses.so.6 -> libncurses.so.6.1
-rwxr-xr-x 1 root root 166952 10. Sep 14:54 /lib64/libncurses.so.6.1
lrwxrwxrwx 1 root root     18 10. Sep 14:53 /lib64/libncursesw.so.6 -> libncursesw.so.6.1
-rwxr-xr-x 1 root root 240864 10. Sep 14:54 /lib64/libncursesw.so.6.1
lrwxrwxrwx 1 root root     15 10. Sep 14:54 /lib64/libtinfo.so.6 -> libtinfo.so.6.1
-rwxr-xr-x 1 root root 189296 10. Sep 14:54 /lib64/libtinfo.so.6.1
lrwxrwxrwx 1 root root     16 11. Mai 2022  /lib64/libtinfow.so.6 -> libtinfow.so.6.1
-rwxr-xr-x 1 root root  10072 10. Sep 14:54 /lib64/libtinfow.so.6.1

gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/7/lto-wrapper
OFFLOAD_TARGET_NAMES=hsa:nvptx-none
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go --enable-offload-targets=hsa,nvptx-none, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/7 --enable-ssp --disable-libssp --disable-libvtv --disable-libcc1 --disable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-7 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --build=x86_64-suse-linux --host=x86_64-suse-linux
Thread model: posix
gcc version 7.5.0 (SUSE Linux) 

gcc -print-search-dirs
install: /usr/lib64/gcc/x86_64-suse-linux/7/
programs: =/usr/lib64/gcc/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/bin/
libraries: =/usr/lib64/gcc/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/lib/x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../x86_64-suse-linux/7/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../lib64/:/lib/x86_64-suse-linux/7/:/lib/../lib64/:/usr/lib/x86_64-suse-linux/7/:/usr/lib/../lib64/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../../x86_64-suse-linux/lib/:/usr/lib64/gcc/x86_64-suse-linux/7/../../../:/lib/:/usr/lib/

For the conftest standalone check I have put the generated code into conftest.c and called the compiler by conftest.sh.
The output you can find in conftest.log
conftest.log.gz
conftest.sh.gz
conftest.c.gz