id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
5415	It's invalid to use libncursesw.so as a drop-in of libncurses.so	Xi Ruoyao	Xi Ruoyao	"We are doing:

{{{
echo ""INPUT(-lncursesw)"" > $LFS/usr/lib/libncurses.so

for lib in ncurses form panel menu ; do
    rm -vf                    /usr/lib/lib${lib}.so
    echo ""INPUT(-l${lib}w)"" > /usr/lib/lib${lib}.so
done
}}}

Now to me this seems invalid: a program can (and should) use libncursesw.so instead of libncurses.so iff -D_XOPEN_SOURCE is defined to an integer >= 500.  Otherwise the data structure definitions in ncurses headers will mismatch with libncursesw.so, causing an ABI mismatch.

If a package uses ncursesw6-config or pkg-config to check for ncurses, it will pick up -D_XOPEN_SOURCE=600 in CFLAGS, then using libncursesw.so will be valid.  But if ncursesw6-config or pkg-config is invoked, it should say ""-lncursesw"" instead of ""-lncurses"" anyway.

An exception is if a program only uses the terminal info functionalities of ncurses, it can use either libncurses.so or libncursesw.so because the terminal info functionaries are same in both libraries.  So the distros shipping both libncurses.so and libncursesw.so configures ncurses to separate terminal info into libtinfo.so (thus these functionalities are not duplicated).

For LFS IMO we should stop creating libncurses.so, libpanel.so, etc. and create libtinfo.so -> libncursesw.so.  The symlinks libncurses.pc, libpanel.pc etc. should still be created because they provide a correct combination of CFLAGS (-D_XOPEN_SOURCE=600) and LDFLAGS (-lncursesw)."	defect	closed	normal	12.1	Book	git	normal	fixed