Created attachment 118649 [details] [review]
The current patch we use

(In reply to comment #0)
> In our ncurses 5.6, tgetent is provided by libtinfo, not by libncurses.

Just to clarify, does that mean that this is a ncurses upstream feature, or does "our" imply it's a distro specific thing?

We use ncurses 5.6 patched up to 5.6-20080927 (official patches) - it doesn't seem to be a local change.

Are you using zdef linker stuff?  ncurses links to tgetent, right?

$ nm -D /usr/lib/libncurses.so | grep tget

$ nm -D /usr/lib/libtinfo.so | grep tget
0000a632 T tgetent
0000a48e T tgetflag
0000a3f0 T tgetnum
0000a521 T tgetstr

$ ldd /usr/lib/libncurses.so
	linux-gate.so.1 =>  (0xb7fd2000)
	libc.so.6 => /lib/libc.so.6 (0xb7e4e000)
	libdl.so.2 => /lib/libdl.so.2 (0xb7e4a000)
	libtinfo.so.5 => /lib/libtinfo.so.5 (0xb7e24000)
	/lib/ld-linux.so.2 (0xb7fd3000)

We link everything with --as-needed to eliminate unneeded deps so this might be part of the cause but in that case using libtinfo should also work for you (and fix it for us).

*ping*

I like to fix this, but the part of configure.in the patch touches is so ugly I can't convince myself to commit the patch without a major cleanup of the configure stuff.  Lets see if Chris or ChPe beat me to it.

I had the same problem :) This code is totally intraceable, so I didn't want to risk touching it.

Created attachment 123825 [details] [review]
proposed patch

I tried to reverse-engineer that configure mess; this patch implements a hopefully more readable variant. I've added libtinfo checks in there. The lib check was adapted from bash's BASH_CHECK_LIB_TERMCAP; not sure the libc case is used on any platform or which headers to check for in this case...

I guess I could test this by just committing it and waiting for bug reports to come in :)

Sounds good to me.

Committed.