Opened 10 months ago
Closed 10 months ago
#5415 closed defect (fixed)
It's invalid to use libncursesw.so as a drop-in of libncurses.so
Reported by: | Xi Ruoyao | Owned by: | Xi Ruoyao |
---|---|---|---|
Priority: | normal | Milestone: | 12.1 |
Component: | Book | Version: | git |
Severity: | normal | Keywords: | |
Cc: |
Description
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).
Change History (7)
follow-up: 2 comment:1 by , 10 months ago
follow-up: 3 comment:2 by , 10 months ago
Replying to Bruce Dubbs:
We've been doing the above for many years. What is broken? If it's not broken, don't fix it.
It contradicts with what we are saying in the book:
--enable-widec
This switch causes wide-character libraries (e.g., libncursesw.so.6.4) to be built instead of normal ones (e.g., libncurses.so.6.4). These wide-character libraries are usable in both multibyte and traditional 8-bit locales, while normal libraries work properly only in 8-bit locales. Wide-character and normal libraries are source-compatible, but not binary-compatible.
"Not binary-compatible" means this is invalid. And I don't want to update the description to something like "hey, we know this is invalid but it works for years" :(.
comment:3 by , 10 months ago
Replying to Xi Ruoyao:
Replying to Bruce Dubbs:
We've been doing the above for many years. What is broken? If it's not broken, don't fix it.
It contradicts with what we are saying in the book:
--enable-widec
This switch causes wide-character libraries (e.g., libncursesw.so.6.4) to be built instead of normal ones (e.g., libncurses.so.6.4). These wide-character libraries are usable in both multibyte and traditional 8-bit locales, while normal libraries work properly only in 8-bit locales. Wide-character and normal libraries are source-compatible, but not binary-compatible.
"Not binary-compatible" means this is invalid. And I don't want to update the description to something like "hey, we know this is invalid but it works for years" :(.
So this is broken for the educational purpose as we are actively telling people to forcefully squash ABI-incompatible things together and expect the result to work. But here it just *happens* to work and technically it's as bad as linking gtk2 to gtk3.
comment:4 by , 10 months ago
BTW I'd like to say the ABI scheme of ncurses is stupid. They really should have made ABI version 6 always wide-character...
comment:5 by , 10 months ago
Hmm, removing these links seems a bad idea because many packages only checks libncurses.so (without checking libncursesw.so, nor libtinfo.so) for terminfo. A much easier solution may be simply patching /usr/include/ncurses.h to always define NCURSES_WIDECHAR to 1.
I'll test this tomorrow...
comment:6 by , 10 months ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
We have a dozen of tickets now (including 3 security fixes) and Linux 6.7.1 is out. And we better do an update before Feb to settle other things down before new Binutils and Glibc.
comment:7 by , 10 months ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
We've been doing the above for many years. What is broken? If it's not broken, don't fix it.