ncurses-interface.o: undefined reference to symbol 'keypad'

[fancywriter]

Can't build the fdupes-2.0.0 from sources, see the following message after make:

make  all-am
make[1]: Entering directory '/var/tmp/portage/app-misc/fdupes-2.0.0/work/fdupes-2.0.0'
x86_64-pc-linux-gnu-gcc  -march=native -O2 -pipe  -Wl,-O1 -Wl,--as-needed -o fdupes fdupes.o ncurses-commands.o ncurses-getcommand.o ncurses-interface.o ncurses-print.o ncurses-prompt.o ncurses-status.o commandidentifier.o errormsg.o wcs.o dir.o log.o fmatch.o sigint.o flags.o mbstowcs_escape_invalid.o positive_wcwidth.o md5/md5.o  -lpcre2-32 -lncursesw 
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ncurses-interface.o: undefined reference to symbol 'keypad'
/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: /lib64/libtinfow.so.6: error adding symbols: DSO missing from command line
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:512: fdupes] Error 1
make[1]: Leaving directory '/var/tmp/portage/app-misc/fdupes-2.0.0/work/fdupes-2.0.0'
make: *** [Makefile:408: all] Error 2

What could be a reason? Of course ncurses is installed (tried 6.1 and 6.2). What am I doing wrong?

[fancywriter]

-ltinfo flag seems to be needed for gcc. But why isn't this added by make and autoreconf? :thinking:

[fancywriter]

Unfortunately, this didn't help after all. The binary is built correctly, works when ncurses is not used. However, it it tries to invoke ncurses functions, I see segmentation fault.

Tried with gdb:

(gdb) run -rd .
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ec2530 in _nc_setupscreen_sp () from /lib64/libncursesw.so.6

My ncurses is 6.2... trying to run it inside konsole terminal emulator. How well was this tested? Do you need any assistance? Didn't program in C and ncurses much to be honest.

@adrianlopezroche

[fancywriter]

(gdb) backtrace 
#0  0x00007ffff7ec2530 in _nc_setupscreen_sp () from /lib64/libncursesw.so.6
#1  0x00007ffff7ebddfc in newterm_sp () from /lib64/libncursesw.so.6
#2  0x00007ffff7ebe279 in newterm () from /lib64/libncursesw.so.6
#3  0x0000555555557e87 in main (argc=3, argv=<optimized out>) at fdupes.c:1542

[fancywriter]

https://github.com/adrianlopezroche/fdupes/blob/791fc12a093b77e8e897241bff731d6ec1e8f5b9/fdupes.c#L1542-L1550 - this is where segmentation fault occurs. :thinking: I suspect it's newterm, what could do unexpected operation.

TERM variable for me has the following content:

$ echo $TERM
xterm-256color

If it could be useful.

[fancywriter]

From man newterm:

   newterm
       A program that outputs to more than one terminal should use the newterm routine for each terminal instead of initscr.  A program that needs to inspect capa‐
       bilities, so it can continue to run in a line-oriented mode if the terminal cannot support a screen-oriented program, would also use newterm.   The  routine
       newterm  should  be called once for each terminal.  It returns a variable of type SCREEN * which should be saved as a reference to that terminal.  newterm's
       arguments are

       ·   the type of the terminal to be used in place of $TERM,

       ·   a file pointer for output to the terminal, and

       ·   another file pointer for input from the terminal

       If the type parameter is NULL, $TERM will be used.

Correct me if I am wrong, this function return a pointer to the SCREEN, which is used only once (in if-statement) and never saved to any variable, never cleared, so it could be a memory leak?.. Not related to the segmentation fault error of course, but still...

Another thing, if it already uses $TERM by default, why not to put NULL there, as documentation says? I am not sure I understand what possible string constants could be used as valid "types" of terminal...

[maxatka]

I have the same problem here, on my x86 Gentoo distribution. Why not to use https://autotools.io/pkgconfig/pkg_check_modules.html for all ncurses flags?

[adrianlopezroche]

Correct me if I am wrong, this function return a pointer to the SCREEN, which is used only once (in if-statement) and never saved to any variable, never cleared, so it could be a memory leak?.. Not related to the segmentation fault error of course, but still...

Another thing, if it already uses $TERM by default, why not to put NULL there, as documentation says? I am not sure I understand what possible string constants could be used as valid "types" of terminal...

The reason I call newterm() instead of initscr() is that the latter will terminate the program if the function is unable to initialize the curses terminal whereas the former returns 0. Calling newterm() allows me to fall back to line mode on terminals where curses is unsupported.

I use $TERM because I'm only interested in using the default terminal.

I don't know if there's a function I need to call on newterm()'s return value to clean things up. I've been assuming that calling endwin() is enough for cleanup and I don't need the value for anything else, so I'm intentionally not saving that value anywhere.

[adrianlopezroche]

I have the same problem here, on my x86 Gentoo distribution. Why not to use https://autotools.io/pkgconfig/pkg_check_modules.html for all ncurses flags?

I have limited knowledge of autotools. Explicit linking against tinfo is unnecessary on my system (Linux Mint 19) as the dependency is somehow being satisfied automatically. Furthermore, some systems don't even have a separate tinfo library, its features being built into curses directly. Whatever solution is adopted needs to account for these differences.

[adrianlopezroche]

https://github.com/adrianlopezroche/fdupes/blob/791fc12a093b77e8e897241bff731d6ec1e8f5b9/fdupes.c#L1542-L1550

• this is where segmentation fault occurs. I suspect it's newterm, what could do unexpected operation. TERM variable for me has the following content:

$ echo $TERM
xterm-256color

If it could be useful.

That's the same value $TERM has on my system and nothing blows up.

I wonder what the values of stdout and stdin are on your system. I am assuming stdout and stdin always contain valid values on startup, but maybe not? Could that be causing any issues?