But number 6941 reports that when ncurses 5.0 is installed, the ncurses 4.0
libraries disappear. The bug is marked resolved, and there's a claim in it
that the problem is fixed in ncurses-5.0-2. I did not find that to be the
case. I just installed ncurses-5.0 and it blew away my ncurses 4
libraries, as reported by "rpm --verify ncurses". I had to install the
symbolic links by hand after unpacking the ncurses 5 source RPM to figure
out what they were supposed to be.
Speaking of which, the links created in the install rules of the spec file
for ncurses 5.0 shouldn't be absolute. That is, rather than linking
libncurses.4, libpanel.4, etc., to /usr/lib/libncurses.5,
/usr/lib/libpanel.5, etc., the links should just point to
"lib<whatever>.so.5" in the same directory.
I found out that ldconfig was killing the ncurses 4 links for some reason,
after rebuilding ldconfig (same version) the problem went away.
All this under a powerpc machine so it might be unrelated
It's fixed now (the .so.5 has just been renamed to .so.4, there are no API
Although the API is the same, the ABI is different. The data structures that
ncurses library and applications use depends on the definition of 'bool' in
curses.h. 'bool' is defined to be 'char' on ncurses-5.0 (on i386 platform) while
it can vary on ncurses-4.2 depending on whether a C++ compiler is present on the
building host. This problem has already triggered the bug number 4573.
So I think sharing the same library files for ncurses 5.0 and ncurses 4.2 is a
bad idea. Binaries compiled on RH6.1 will dump core on the next version of RH.