Re: Headsup: ncurses soname bump 5 to 6

[+dickey]

On Thu, Sep 18, 2008 at 8:45 AM, Florian Weimer <[email protected]> wrote:
>>> So the obvious solution seems to me then to build ncurses twice,
>>> providing both libncurses5 and libncurses6 packages. What point do I miss?
>>
>>The crashes that will happen when both are loaded in a
>>process's address space.
>> ... and they couldn't add mouse-wheel support without breaking ABI ?
>
> AFAICT, the issue is that there aren't enough bits in an int to express
> all the button events in the same way as before.  The new ABI reshuffles
> the bits to make more room.
>
> It should be possible to make this change in a less invasive way.

A possible problem case is: an app built against version X of ncurses
tries to load a shared library built against version X+1 of ncurses.
e.g. a CAD vendor ships a binary app linked itself against ncurses.so.5
and also via a library in the distro against ncurses.so.6.
But are there any libraries in linux distros that use ncurses?
As it turns out, yes.  On my system, I see rather a few:

gstreamer-0.10/libgstaasink.so
gstreamer-0.10/libgstcacasink.so
libaa.so.1.0.4
libcaca.so.0.99.13
libcaca++.so.0.99.13
libcwidget.so.3.0.0
libedit.so.2
libform.so.5.6
libformw.so.5.6
libggi.so.2.0.2
libguilereadline-v-12.so.12.3.1
libmenu.so.5.6
libmenuw.so.5.6
libpanel.so.5.6
libpanelw.so.5
libvte.so.9.2.17
libzephyr.so.3.0.0
python2.5/lib-dynload/readline.so
python-support/python-vte/python2.4/gtk-2.0/vtemodule.so

So if a binary app happens to link in any of those and also ncurses itself,
there's a potential conflict.   I don't know if there's an actual conflict, I
haven't looked.

I didn't see any recent discussion about abi stability
http://lists.gnu.org/mailman/listinfo/bug-ncurses
If there is a realistic problem case, perhaps we should also discuss it there.
- Dan