[+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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]